یکی از مشکلات رایج در محیطهای Oracle Data Guard، ایجاد Archive Gap گسترده بین Primary و Standby است. در برخی موارد به دلیل حذف شدن Archive Logها، کمبود فضای FRA، خرابی Control File یا از دست رفتن بخشی از فایلهای Standby، امکان دریافت و اعمال آرشیوها وجود ندارد و فرآیند Managed Recovery در وضعیت WAIT_FOR_GAP باقی میماند.
در این مقاله فرآیند بازسازی Standby Database در Oracle 19c بدون نیاز به Duplicate کامل و تنها با استفاده از قابلیت Restore From Service تشریح میشود.
علائم اولیه مشکل
در بررسی وضعیت Data Guard مشاهده شد که فرآیند MRP در وضعیت WAIT_FOR_GAP قرار گرفته است:
select process,sequence#,status
from v$managed_standby;
خروجی:
MRP0 2478 WAIT_FOR_GAP
این وضعیت نشان میدهد که Standby منتظر دریافت Archive Log هایی است که در دسترس نیستند.
بررسی Archive Log های موجود
ابتدا وضعیت FRA بررسی شد:
du -sh /backup/fast_recovery_area/*
خروجی نشان داد که روی سرور Standby فقط Archive Log های جدید موجود هستند و بخش قابل توجهی از Archive Log های مورد نیاز برای ادامه Recovery از بین رفتهاند.
بررسی پوشهها نیز نشان داد که:
/backup/fast_recovery_area/TRDAFRA2/archivelog
شامل Archive Log های جدید است اما توالیهای قدیمی مورد نیاز جهت رفع Gap وجود ندارند.
بررسی تنظیمات FAL
تنظیمات FAL بررسی شد:
show parameter fal
خروجی:
fal_server = tradecdbaf,tradecdb
تنظیمات صحیح بودند اما به دلیل از بین رفتن Archive Log های مورد نیاز، FAL قادر به رفع Gap نبود.
اطمینان از نقش دیتابیس
ابتدا Instance در حالت Mount بالا آورده شد:
startup nomount;
alter database mount;
سپس نقش دیتابیس بررسی شد:
select database_role from v$database;
خروجی:
PHYSICAL STANDBY
بنابراین ساختار Data Guard سالم بود و تنها نیاز به همگامسازی مجدد داشت.
بازیابی Standby Control File از Primary
اولین مرحله، دریافت مجدد Control File از Primary بود.
اتصال به RMAN:
rman target /
بازیابی Control File:
restore standby controlfile
from service tradecdbaf;
مزیت این روش آن است که RMAN مستقیماً از طریق شبکه به Primary متصل شده و آخرین نسخه Standby Control File را دریافت میکند.
پس از اتمام عملیات:
alter database mount;
Catalog کردن فایلهای موجود
از آنجا که Datafile ها روی ASM موجود بودند اما در Control File جدید ثبت نشده بودند، لازم بود فایلها مجدداً Catalog شوند.
catalog start with '+DATA';
در این مرحله RMAN کلیه Datafile های موجود روی ASM را شناسایی و ثبت کرد.
نمونه فایلهای شناسایی شده:
+DATA/TRDAFRA2/DATAFILE/system
+DATA/TRDAFRA2/DATAFILE/sysaux
+DATA/TRDAFRA2/DATAFILE/users
استفاده از Datafile های موجود
برای استفاده از فایلهای فعلی روی ASM از دستور زیر استفاده شد. دقت کنید که اگر اینکار رو انجام ندهید، کل دیتابیس در مسیر جدیدی ریستور میشه:
switch database to copy;
در این مرحله Control File جدید به Datafile های موجود روی ASM متصل شد.
نمونه خروجی:
datafile 1 switched
datafile 3 switched
datafile 4 switched
...
این مرحله بسیار مهم است زیرا از انتقال مجدد چندین ترابایت داده جلوگیری میکند.
خطای ORA-19573
در اجرای مجدد Restore با خطای زیر مواجه شدیم:
ORA-19573: cannot obtain exclusive enqueue for datafile
ORA-19890: data file already in use
ORA-45909: restore, recover or block media recovery may be in progress
علت خطا فعال بودن Recovery روی Standby بود.
برای رفع آن:
recover managed standby database cancel;
سپس عملیات Restore مجدداً اجرا شد.
همگامسازی Datafile ها از طریق شبکه
اکنون RMAN فقط فایلهایی را که نیاز به بروزرسانی داشتند از Primary دریافت کرد:
restore database from service tradecdbaf;
خروجی نشان داد که Datafile ها یکییکی از Primary دریافت و بروزرسانی شدند:
restoring datafile 1
restoring datafile 3
restoring datafile 4
...
در این روش Oracle فقط Block های مورد نیاز را منتقل میکند و سرعت عملیات بسیار بالاتر از Duplicate کامل است.
مدیریت Online Redo Log ها
پس از بازسازی Control File مشاهده شد که گروههای Redo Log قدیمی در Standby وجود دارند.
ابتدا وضعیت بررسی شد:
select * from v$log;
سپس تمام گروهها Clear شدند:
alter database clear logfile group n;
برای تمامی گروههای موجود.
حذف Redo Log های قدیمی
پس از Clear شدن گروهها:
alter database drop logfile group n;
برای تمامی گروههای قبلی اجرا شد.
ایجاد مجدد Online Redo Log
با توجه به تنظیمات:
show parameter online
مشخص شد فایلها در دو مقصد زیر ساخته میشوند:
+DATA
/backup/fast_recovery_area
سپس گروههای جدید ایجاد شدند:
alter database add logfile size 209715200;
چندین بار اجرا شد تا تعداد مورد نیاز Log Group ها ایجاد شود.
ایجاد Standby Redo Log
در مرحله بعد Standby Redo Log ها ایجاد شدند:
alter database add standby logfile size 209715200;
این دستور نیز به تعداد مورد نیاز اجرا شد.
وجود Standby Redo Log برای Real-Time Apply الزامی است.
فعال کردن مجدد Standby File Management
در زمان انجام تغییرات:
alter system set standby_file_management=manual;
تنظیم شده بود.
پس از پایان عملیات:
alter system set standby_file_management=auto;
بازگردانده شد.
راهاندازی مجدد دیتابیس
در پایان دیتابیس ریستارت شد:
shutdown immediate;
startup;
خروجی:
Database mounted.
Database opened.
نتیجهگیری
در این سناریو Standby Database به دلیل Archive Gap شدید و عدم دسترسی به Archive Log های مورد نیاز از Primary عقب افتاده بود.
به جای Duplicate کامل دیتابیس، از قابلیت قدرتمند Restore From Service در Oracle 19c استفاده شد و با مراحل زیر Standby در مدت کوتاهی بازسازی شد:
- دریافت Standby Control File از Primary
- Catalog کردن Datafile های موجود روی ASM
- اتصال Control File جدید به Datafile های موجود با Switch Database To Copy
- همگامسازی Datafile ها از طریق شبکه
- بازسازی Online Redo Log ها
- ایجاد Standby Redo Log ها
- فعالسازی مجدد Standby File Management
این روش در محیطهای بزرگ که حجم دیتابیس چند ترابایت است، میتواند ساعتها یا حتی روزها زمان بازیابی را کاهش دهد و از انتقال غیرضروری داده جلوگیری کند.