در زمان اجرای دستور IMPDP، بخشهایی از عملیات امکان اجرای parallel را ندارند ایجاد constraint یکی از این قسمتهاست. اوراکل قبل از ایجاد constraint باید یکبار Validate را برای دیتای جاری جدول اجرا کند. با هر بار اجرای Validate، نیاز است یک بار Full table scan انجام شود که می تواند بسیار زمانبر باشد. دو constraint زیر را در نظر بگیرید:
alter table MYTB add constraint CHECK1 check (col3 > 50); alter table MYTB add constraint CHECK2 check (col9 in (5,15));
جدول mytb را حذف می کنیم و از طریق dumpای که از این جدول داریم، آن را مجددا ایجاد می کنیم:
SQL> drop table mytb; Table dropped.
W-1 Processing object type TABLE_EXPORT/TABLE/TABLE_DATA W-1 . . imported "USEF"."MYTB" 19 GB 337830912 rows in 83 seconds using external_table W-1 Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT W-1 Completed 2 CONSTRAINT objects in 208 seconds
همانطور که می بینید، زمان ایجاد دو constraint حدودا 3 دقیقه به طول انجامیده است در حالیکه ایجاد جدول در زمان 1 دقیقه انجام شده است. این دو constraint در وضعیتENABLED و VALIDATED ایجاد شده اند:
SQL> select owner,constraint_name,status,validated from user_constraints; OWNER CONSTRAINT STATUS VALIDATED ---------- ---------- -------- ------------- USEF CHECK1 ENABLED VALIDATED USEF CHECK2 ENABLED VALIDATED
از اوراکل 23ai(و از اوراکل 19.23) برای پارامتر Transform در دستور IMPDP، گزینه جدیدی به نام constraint_novalidate اضافه شده است که از طریق آن می توان constraintها را در حالت ENABLED NOT VALIDATED برگرداند:
Transform=constraint_novalidate:y
در این صورت، در زمان برگرداندن dump، سرعت ایجاد constraintها بسیار افزایش می یابد چرا که دیتای جاری جداول بررسی نمی شوند البته عبارت constraint_novalidate صرفا در زمان ساخت constraint مانع از بررسی صحت دیتا می شود و بعد از عملیات IMPDP، این Constraintها برای دیتای جدید اعمال خواهند شد.
عملیات فوق را با پارامتر Transform=constraint_novalidate:y تکرار کرده ایم:
W-1 Processing object type TABLE_EXPORT/TABLE/TABLE_DATA W-1 . . imported "USEF"."MYTB" 19 GB 337830912 rows in 82 seconds using external_table W-1 Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT W-1 Completed 2 CONSTRAINT objects in 1 seconds
همانطور که می بینید، زمان برگرداندن جدول، همان 82 ثانیه هست ولی constraintها در مدت زمان 1 ثانیه ایجاد شده اند.
اگر بعد از عملیات import کماکان نگران invalid بودن دیتایی که از دیتابیس مبدا به مقصد انتقال داده شده اند، هستید، پیشنهاد می شود دستور validate را در زمانی مناسب اجرا کنید. این کار منجر به lock شدن جدول نخواهد شد و I/O زیادی را به همراه خواهد داشت.
در قسمت زیر، در session 1 جدول را به صورت row exclusive قفل کرده ایم و در session 2 عملیات validate را به صورت parallel انجام داده ایم که هر دو به صورت موازی اجرا شده اند و اجرای دستور validate منجر به lock شدن mytb نشده است:
-session 1: SQL> delete mytb where rownum=1; 1 row deleted.
--session 2: SQL> alter session force parallel query; Session altered SQL> alter table mytb modify constraint CHECK1 validate; Table altered Executed in 14/951 seconds SQL> alter table mytb modify constraint CHECK2 validate; Table altered Executed in 15/448 seconds
این دو constraint در وضعیت ENABLED VALIDATED قرار گرفته اند:
SQL> select owner,constraint_name,status,validated from user_constraints; OWNER CONSTRAINT STATUS VALIDATED ---------- ---------- -------- ------------- USEF CHECK1 ENABLED VALIDATED USEF CHECK2 ENABLED VALIDATED