اوراکل 12c قابلیتهای را در زمینه Data Pump ارائه کرد که قبلا بعضی از آنها را مورد بررسی قرار داده ایم. در این متن به دو بهبود ساده اوراکل 12cR2 در این زمینه خواهیم پرداخت.
آشنایی با مفهوم Editioning و پارامترهای آن در دیتاپامپ
احتمالا تاکنون هنگام ایجاد یک آبجکت مانند ویو، با این خطا مواجه شده اید:
ORA-00955: name is already used by an existing object
همانطور که می دانید این خطا زمانی رخ می دهد که آبجکتی با نام مورد نظر قبلا در بانک موجود باشد.
گاهی ممکن است، بدلایل مختلف از جمله توسعه و تغییر در برنامه یا ساختار بانک اطلاعاتی، نیاز باشد در متن یک ویو یا یک پروسیجر یا دستورات یک trigger تغییراتی را ایجاد کرده و عملکرد جدید آنها را قبل از استقرار کامل در سیستم تست کنیم.
مسلما ایجاد این آبجکتها با ساختار و نام جدید، نیاز به تغییرات در برنامه کاربردی دارد، که البته این موضوع خوشایند و مطلوب برنامه نویسان وکاربران نمی باشد.
اوراکل از نسخه ی 11g به بعد، قابلیت جدیدی با عنوان editioning را به پایگاه داده خود افزوده است.
پارامترهای INCLUDE، EXCLUDE و QUERY در expdp/impdp
در زمان استفاده از Data Pump، می توان در چهار سطح FULL/TABLESPACE/SCHEMA/TABLES عملیات export/import را انجام داد در مواردی ممکن است نیاز باشد تا objectهای خاصی را مستثنی کرد و یا صرفا بعضی از این objectها را در این عملیات شرکت داد، در این صورت می توان از سه پارامتر INCLUDE، EXCLUDE و QUERY استفاده کرد که در ادامه به بررسی آنها می پردازیم.
پارامترهای REMAP در ابزار IMPDP
بطور معمول و پیش فرض در هنگام import داده ها در بانک مقصد، جداول با همان نام قبلی و در همان schema و tablespace بارگذاری می شوند، مگر آنکه با استفاده از برخی پارامترها نام و مکان آنها را تغییر دهیم که در ادامه با این پارامترها آشنا می شویم.
پارامترهای کنترل job در ابزار EXPDP و IMPDP
همانطور که در مطلب “آشنایی با Data Pump” اشاره شد، پروسس master برای انجام عملیات، jobای را ایجاد می کند که در طول عملیات export/import ، می توان با ارجاع به نام آن job، عملیات مربوطه را کنترل نمود. برای مثال می توان اجرای دستورات را موقتا متوقف کرد و یا بعد از توقف، عملیات را مجددا از سر گرفت.
قصد داریم در این متن پارامترهای مربوط به مانیتور و کنترل jobها را شرح دهیم.
Substitution Variableهای جدید برای expdp/impdp
در زمان تهیه دامپ به صورت همروند، خروجی دامپ در فایلهای متعددی قرار خواهد گرفت که در نسخه های قبل از 12cR2، اسامی هر کدام از این فایلها با کمک متغیر %U و با یک شماره از هم متمایز می شد به عبارت دیگر، ایجاد دامپ همروند تنها از طریق این Substitution Variable قابل انجام بود:
expdp \’sys/sy AS SYSDBA\’ directory=dr dumpfile=dump_%U.dmp schemas=usef parallel=4
Export: Release 11.2.0.4.0 – Production on Sun Apr 15 16:33:35 2018
Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is:
/u01/oracle/dump_01.dmp
/u01/oracle/dump_02.dmp
/u01/oracle/dump_03.dmp
پارامتر remap_directory در دستور impdp
قبل از برگرداندن دامپ به صورت کامل(full=y)، باید مسیر دیتافایلها را ایجاد نمود در غیر این صورت، عملیات بازیابی در هنگام ایجاد tablespace با خطا متوقف خواهد شد:
ORA-39083: Object type TABLESPACE:”TBS2″ failed to create with error:
ORA-01119: error in creating database file ‘/db/oradata/datafile/tbs02.dbf’
غیرفعال سازی logging بهنگام impdp
برای بهبود سرعت برگرداندن اطلاعات dumpfile، می توان از پارامتر logging به هنگام اجرای دستور impdp استفاده کرد و با تنظیم این پارامتر(که از اوراکل 12c ارائه شد) به مقدار DISABLE_ARCHIVE_LOGGING:Y، مانع از ایجاد آرشیولاگ در زمان impdp شد:
impdp directory=usef dumpfile=c.dmp schemas=usef TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y
Import: Release 12.1.0.2.0 – Production on Tue Jul 5 15:02:28 2016
. . imported “USEF”.”COM_LOC” 533.490 MB 226333 rows
در صورت استفاده از data guard در چنین محیطی، اطلاعات import شده به سمت data guard منتقل نخواهند شد و با رجوع به این جدول در محیط data guard، با خطای زیر مواجه خواهیم شد:
select count(*) from usef.com_loc
ORA-01578: ORACLE data block corrupted (file # 6, block # 555)
ORA-01110: data file 6: ‘/u02/oradata/usef2/datafile/users.258.916411623’
ORA-26040: Data block was loaded using the NOLOGGING option
البته اگر دیتابیس در حالت force logging قرار داشته باشد، امکان استفاده از چنین ویژگی ای وجود ندارد(معمولا قبل از راه اندازی data guard، اوراکل تاکید دارد تا این گزینه فعال شود).
این ویژگی در سطح ایندکس هم قابل استفاده می باشد:
TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y:INDEX