Transportable Tablespaces در اوراکل چیست

آوریل

Tablespace های قابل حمل که از اوراکل 8i معرفی شدند، این امکان را می دهند تا دسته ای از Tablespace ها از یک پایگاه داده با پایگاه داده دیگر منتقل شوند. Transportable Tablespaces که از این پس TTS می نمامیم، نسب به export/import یا upload/load سریعتر است و به این خاطر است که Datafile ها که تمامی داده ها را در خود دارند تنها بر روی مقصد کپی می شوند و سپس می توان از Data Pump برای انتقال متادیتا های اشیا Tablespace به محل جدید استفاده نمود.

در اوراکل 8i این محدودیت وجود داشت که تنها حمل Tablespace از پلفترم های یکسان و با پشتیبانی از اندازه بلاک های همسان مقدور بود. همچنین امکان rename کردن Tablespace نبود. با معرفی اوراکل 9i دو محدودیت اندازه بلاک های همسان در مبدا و مقصد و عدم rename کردن Tablespace ها برداشته شد. در 11g امکان حمل میان پلتفرم های متفاوت وجود دارد. با پرس و جو از View به نام V$TRANSPORTABLE_PLATFORM می توانید از پلتفرم های مورد پشتیبانی و فرمت ENDIAN هر کدام اطلاع پیدا کنید.

COLUMN PLATFORM_NAME FORMAT A32

;SELECT * FROM V$TRANSPORTABLE_PLATFORM

در ارتباط با Endian می توانید ویکی پدیای فارسی و انگلیسی را مطالعه کنید. اما به طور کلی یک سیستم Little Endian بایت های کم اهمیت را در آدرس های پایین ترحافظه و آدرس های پر اهمیت را در بایت های بالا تر حافظه ذخیره می کند. سیستم عامل های لینوکس و ویندوز از Little Endian استفاده می کنند. Big Endian بدین معنی است که بایت های پر اهمیت در آدرس هایی پایین تر حافظه و بیت های کم اهمیت در آدرس های بالاتر حافظه ذخیره می شوند. سیستم عامل های سولاریس، HPUX و اپل مکینتاش از Big Endian استفاده می کنند.

محدودیت ها در استفاده از Transportable Tablespace

هر دو پلتفرم مبدا و مقصد باید دارای character set و national character set همسان باشند.
نمی توانید یک Tablespace را از مبدا به مقصد حمل کنید در صورتی که Tablespace همنامی در مقصد وجود داشته باشد.
نمی توانید یک Tablespace رمز شده را به پتلتفرمی با Endian متفاوت انتقال دهید.
از اوراکل 10gR2 نمی توانید Tablespace ها با فرمت XMLTypes را حمل کنید. از اوراکل 11gR1 تنها می توانید از Data Pump برای حمل Tablespace ها با نوع XMLTypes استفاده کنید.
یک Tablespace باید self-contained باشد. (با این مفهوم در ادامه آشنا خواهید شد).

از اینجا می توانید اطلاعات بیشتری را کسب کنید.

روال و فرایند انجام Transportable Tablespaces میان پایگاه داده

گام های زیر خلاصه ای از فرایند Transportable Tablespaces را بیان می کند.

گام 1 : برای cross-platform نخست Endian هر پلتفرم را با پرس و جو از V$TRANSPORTABLE_PLATFORM مشخص کنید. اگر پلتفرم های یکسانی را برای Transportable Tablespaces دارید نیازی به انجام این گام ندارید.
گام 2 : برگزیدن یک مجموعه از Tablespace های self-contained
گام 3 : یک transportable tablespace set را ایجاد کنید. یک transportable tablespace set یا transportable set (مجموعه از Tablespace های قابل حمل)، Datafile ها برای مجموعه Tablespace های حمل شده و فایلی شامل اطلاعات ساختار (متادیتا) مجموعه Tablepace ها که می توایند این فایل را توسط Data Pump تهیه (Export) کنید.

در صورتی که حمل یا transport کردن مجموعه Tablespace را از پلتفرم مبدا با Endian متفاوت از مقصد انجام داده اید، می بایست فرمت Endian مجموعه Tablespace را به فرمت مقصد تبدیل کنید.

گام 4 : حمل یا Transport کردن مجموعه Tablespace. در این گام Datafile ها و فایل export شده که شامل ساختار Tablespace است را به مکانی که پایگاه داده مقصد به آن دسترسی داشته باشد منتقل می کنیم.

انجام عامل تبدیل endian در حالتی که پلتفرم های مبدا و مقصد فرمت endian متفاوتی دارند را یا می توان در همان گام سه در مبدا انجام داد که source-side گفته می شود و یا اینکه در گام 4 و در مقصد انجام داد که target-side گفته می شود.

گام 5 : Import کردن مجموعه Tablespace. در این گام از Data Pump برای import کردن فایل شامل ساختار (متا دیتا) مجموعه Tablespace به پایگاه داده مقصد استفاده می کنیم.

این مطلب و آنچه که گفته شد بر اساس اوراکل 11gR1 و مستندات آن می باشد.

مثالی از اوراکل 11g R1

این مثال بر اساس مستندات اوراکل 11g R1 است که 5 گام گفته شده را شرح می دهد. اما پیش از پرداختن به مثال از حمل Tablespace چند مورد لازم به ذکر است

این مثال با توجه به متفاوت بودن فرمت Endian پایگاه داده های مبدا و مقصد گفته خواهد شد. مجموعه Tablespace یا Tablespace set دارای دو Tablespace به نام های sales_1 و sales_2 است.

برای انجام این مثال از محیط SQL*PLUS استفاده کرده ایم، اما می توانید به راحتی موارد فوق را توسط Enterprise Manager نیز انجام دهید.
عبارت “self-contained” به این مفهوم اشاره می کند که ممکن است به طور فیزیکی یا منطقی وابستگی های میان اشیا درون مجموعه Tablespace و اشیایی خارج از مجموعه وجود داشته باشد و شما تنها می توانید مجموعه Tablespace های self-contained را حمل کنید و این یعنی اینکه نباید هیچ گونه ارجاعی از درون مجموعه Tablespace به نقطه ای خارج از Tablespace ها وجود داشته باشد. در ادامه نمونه مواردی که مفهوم self-contained را نقض می کند اشاره شده است :

1 – ایندکسی درون مجموعه Tablespace برای جدولی خارج از مجموعه باشد.

2 – جدولی که تا حدی پارتیشن (Partially) بندی شده است در مجموعه باشد. (از این پس منظور از مجموعه یعنی مجموعه Tablespace). یا باید تمام پارتیشن جدول پارتیشن بندی شده در مجموعه باشد و یا هیچ پارتیشنی از جدول پارتیشن بندی شده در مجموعه نباشد (همه یا هیچ).

3 – جدولی در مجموعه وجود دارد که شامل ستونی از نوع LOB بوده که به LOB هایی خارج از Tablespace اشاره می کند. (طبق مطلب مرتبط با نوع داده ای Large Object فایل های LOB درون Datafile ذخیره می شوند و مفهوم جمله گفته شده در ابتدا یعنی اینکه ستون LOB در مجموعه فایل آن در Datafile ای خارج از مجموعه باشد.)

برای اطلاع از اینکه آیا مجموعه Tablespace به صورت self-contained است یا نه می توانید از پروسیجر TRANSPORT_SET_CHECK از بسته DBMS_TTS استفاده کنید. کاربر SYS بلقوه مجوز اجرای بسته و پروسیجر فوق را دارد اما دیگر کاربران باید مجوز EXECUTE_CATALOG_ROLE را داشته باشند. در استفاده از DBMS_TTS.TRANSPORT_SET_CHECK باید فهرستی از نام Tablespace ها در مجموعه را مشخص کنید. در مثال زیر دو Tablespace به نام های sales_1 و sales_2 آورده شده اند. TRUE در خط زیر یعنی اینکه آیا دو Tablespace مشخص شده به صورت self-contained هستند.

;(EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK(‘sales_1,sales_2′, TRUE

گام نخست از فرایند : در این گام اگر پلتفرم های مبدا و مقصد متفاوت هستند باید از فرمت endian آنها آگاه شویم. اگر می دانید که مبدا و مقصد پلتفرم یکسانی دارند پس نیازی به انجام این گام نمی باشد، در غیر این صورت باید پرس و جوی زیر را هم بروی مبدا و هم بر روی مقصد اجرا کنید تا از فرمت endian آنها مطلع شوید.

SELECT d.PLATFORM_NAME, ENDIAN_FORMAT

FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d

;WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME

برای مثال خروجی های زیر برای مبدا (Source Platform) و مقصد (Target Platform) را نشان می دهد که فرمت endian متفاوت داشته پس لازم است که تبدیل یا در source-side و یا در target-side انجام گیرد.

گام دوم در فرایند : در این گام باید مشخص کنید که آیا Tablespace های درون مجموعه به صورت self-contained هستند یا خیر. همانطور که در بالا گفته شد برای این کار باید یک پروسیچر را اجرا کنید. با توجه به اینکه نام Tablespace های درون مجموعه sales_1 و sales_2 است دستور PL/SQL زیر را (مانند آنچه که در بالا گفته شد) اجرا می کنیم.

;(EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK(‘sales_1,sales_2′, TRUE

پس از انجام و اجرای پرس و جوی زیر بر روی TRANSPORT_SET_VIOLATIONS می توانید تمامی مواردی که self-contained را نقض می کنند را مشاهده کنید. اگر Tablespace های مجموعه self-contained باشند پس نتیجه پر و جو (select زیر) خالی خواهد بود.

;SELECT * FROM TRANSPORT_SET_VIOLATIONS

خروجی شکل زیر نتیجه ای را نشان می دهد که دو مورد نقض : یکی وجود Constraint از نوع کلید خارجی به نام DEPT_FK و دومی جدول پارتیشن بندی شده به نام jim.sales که تا حدی (partially) در مجموعه وجود دارد.

گام سوم در فرایند : در این گام پس از اطمینان از self-contained بودن Tablespace های درون مجموعه باید یک Transportable Tablespace Set ایجاد کنیم. کاربرانی که دارای مجوز EXP_FULL_DATABASE هستند می توانند گام سوم را انجام دهند. نخست Tablespace هایی که در مجموعه هستند را به حالت Read Only می بریم :

;ALTER TABLESPACE sales_1 READ ONLY

;ALTER TABLESPACE sales_2 READ ONLY

در نهایت با استفاده از Data Pump و استفاده از دستور Expdp و گزینه TRANSPORT_TABLESPACES که نام Tablesapce های self-contained و منتخب برای قرار گرفتن در مجموعه، یک مجموعه را در قالب فایل expdat.dmp زیر دایرکتوری dpump_dir ایجاد می کنیم. (مطالعه مطلب مرتبط با دایرکتوری ها در اوراکل) نام Tablespace های منتخب با کاما از هم جدا شده اند. (اجرای دستور زیر باید خارج از محیط SQL*PLUS و محیط خط فرمان سیستم عامل باشد)

EXPDP system/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dirTRANSPORT_TABLESPACES = sales_1,sales_2

اگر فرمت endian در مبدا و مقصد متفاوت بود باید و می خواهید به صورت source-side و پیش از حمل یا Transport عمل تبدیل فرمت endian به فرمت مقصد را انجام دهید، باید از RMAN استفاده کنید. نخست از خط فرمان سیستم عامل (مبدا) به دستور زیر به RMAN متصل شوید. (مطالعه مطلب متصل شدن به RMAN)

/ RMAN TARGET

مطابق با شکل سوم پلتفرم مقصد Microsoft Windows NT است پس لازم است با دستور زیر فرمت Datafile ها را به مقصد تبدیل کنید.

CONVERT TABLESPACE sales_1,sales_2

‘TO PLATFORM ‘Microsoft Windows NT

;’FORMAT ‘/temp/%U

و خروجی مشابه زیر است

Starting backup at 08-APR-03
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00005 name=/u01/oracle/oradata/salesdb/sales_101.dbf
converted datafile=/temp/data_D-10_I-3295731590_TS-ADMIN_TBS_FNO-5_05ek24v5
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00004 name=/u01/oracle/oradata/salesdb/sales_101.dbf
converted datafile=/temp/data_D-10_I-3295731590_TS-EXAMPLE_FNO-4_06ek24vl
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:45
Finished backup at 08-APR-03

و در نهایت با دستور exit از محیط RMAN خارج شوید.

گام چهارم از فرایند : در این گام اقدام به حمل یا Transport کردن Datafile ها و فایل export شده از ساختار Tablespace های درون مجموعه می کنیم. در اینجا دو حالت پیش می اید

هر دوی مبدا و مقصد از سیستم فایل (مانند هارد دیسک متصل به سیستم و تحت کنترل سیستم عامل) استفاده می کنند. می توایند

1 – از دستور های رایج کپی در سیستم عامل های متفاوت مانند copy در ویندوز یا cp در یونیکس ها استفاده کنید.

2 – از بسته DBMS_FILE_TRANSFER استفاده کنید.

3 – از RMAN استفاده کنید.

4 – رایت بر روی CD/DVD و هر امکان دیگری استفاده کنید.

هر دوی مبدا و مقصد از گروه های دیسک Automatic Storage Management یا ASM Disk Groups استفاده می کنند. می توانید

1 – به یا از پوشه sys/asm/ از ftp استفاده کنید.

2 – از بسته DBMS_FILE_TRANSFER استفاده کنید.

3 – از RMAN استفاده کنید.

گام پنجم از فرایند : آخرین گام در فرایند Transport Tablespace است. در این گام مورد مهمی که وجود دارد، اندازه بلاک پایگاه داده است. اگر Tablespace ای را با اندازه بلاک متفاوت به مقصد حمل کرده باشید پس نخست می بایست در پایگاه داده مقصد پارامتر اولیه DB_nK_CACHE_SIZE را تنظیم کنید. به طور مثال اگر مجموعه ای با Tablespace هایی با بلاک های 8 کیلوبایتی را به پایگاه داده ای با بلاک های به اندازه 4 کیلوبایت Transport کرده باشید، پس لازم است در پایگاه داده مقصد پارامتر DB_8K_CACHE_SIZE را تنظیم کنید. برای اطلاع بیشتر از چگونگی تغییر پارامتر DB_nK_CACHE_SIZE اینجا و برای اطلاع از چگونگی تغییر پارامتر های اولیه اینجا را بخوانید.

پس از انجام مورد بالا باید با دستور impdp فایل export و منتقل شده از مبدا را به پایگاه داده import کنید. به طور مثال برای فایل export شده توسط دستور expdp در بالا دستور زیر را استفاده می کنیم.

IMPDP system/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dir

TRANSPORT_DATAFILES= /salesdb/sales_101.dbf,/salesdb/sales_201.dbf

(REMAP_SCHEMA=(dcranney:smith) REMAP_SCHEMA=(jfee:williams

DUMPFILE : نام فایل export شده از مبدا و قرار گرفته در دایرکتوری dpump_dir از مقصد را مشخص می کند. با گزینه DUMPFILE ساختار منطقی Tablespace های مبدا از فایل مشخص شده تحت دایرکتوری dpump_dir به پایگاه داده مقصد منتقب و ساختار object های مبدا در مقصد نیز ساخته می شود. سپس نوبت به معرفی Datafile هایی است که از مبدا به مقصد و زیر دایرکتوری dpump_dir کپی کرده ایم. در اصل تمامی داده های واقعی مانند مقادیر اشیا (مثل مقادیر جداول و ستون ها و سطر هایش) در قالب Datafile ها هستند. این Datafile ها توسط گزینه TRANSPORT_DATAFILES در دستور impdp مشخص می شوند.

از گزینه REMAP_SCHEMA برای تغییر مالک اشیای پایگاه داده استفاده می شود. اگر از REMAP_SCHEMA استفاده نکنید، مالک اشیا همانند آنچه که در مقصد بود به مبدا منتقل می شود و لازم است که همان کاربران در مقصد از قبل وجود داشته باشند در غیر این صورت impdp خطایی را نشان خواهد داد. در مثال بالا اشیا درون مجموعه Tablespace که در مقصد مالک آنها dcranney بود، در مقصد مالکشان به smith تغییر می کند و همین طور برای jfee و williams. در این حالت نیازی به وجود دو کاربر dcranney و williams در مقصد نیست و لازم است از پیش دو کاربر smith و williams در پایگاه داده مقصد وجود داشته باشند.

پس از انجام گام های بالا هنوز Tablespace های حمل شده از مبدا به مقصد به صورت Read Only هستند. می توانید از فایل log ای که در زیر دایرکتوری dpump_dir بررسی کنید و در صورت نیاز آنها را به حالت Read Write بازگردانید.

;ALTER TABLESPACE sales_1 READ WRITE

;ALTER TABLESPACE sales_2 READ WRITE

پس از انجام دو دستور بالا (در صورت نیاز) فرانید Transport Tablespace به اتمار رسید. تمامی مراحل بالا تنها با دستور های expdp و impdp صورت گرفت. البته می توانید از Oracle Enterprise Manager نیز به صورت زیر Transport Tablespace را انجام دهید.