يتيح لك Oracle AI Database 23.26.2 إنشاء قاعدة بيانات قابلة للفصل (PDB) احتياطية وسجلات الـ redo الخاصة بها باستخدام أمر واحد من Data Guard Broker، مما يلغي روتين نسخ الملفات يدويًا الذي لطالما أبطأ عمليات إعداد التعافي من الكوارث.
لماذا يهم هذا الأمر
كان إنشاء PDB احتياطية مادية يتطلب سلسلة من الإجراءات اليدوية: نسخ كل ملف بيانات (datafile) إلى الحاوية الاحتياطية، وبناء سجلات الـ redo الاحتياطية (SRLs) باستخدام أوامر ALTER صريحة، والتحقق المزدوج من التكوين بأكمله. تنطوي كل خطوة على خطر حدوث خطأ مطبعي، أو فقدان ملف، أو عدم تطابق مجموعة السجلات، مما قد يؤخر اختبار التعافي أو، في أسوأ الحالات، يؤدي إلى فشل عملية الـ failover. إن أتمتة هذه العملية تقلل من تلك المخاطر وتفرغ مديري قواعد البيانات (DBAs) للتركيز على مهام ذات مستوى أعلى.
كيف كان يتم بناء الـ PDBs الاحتياطية سابقًا
في بنية الـ multitenant، تستضيف قاعدة بيانات CDB (container database) أساسية واحدة أو أكثر من الـ PDBs. ولحماية الـ PDB، كان على المسؤولين القيام بما يلي:
- تحديد ونسخ كل ملف بيانات من المضيف الأساسي إلى المضيف الاحتياطي.
- إنشاء SRLs يدويًا لتعكس تخطيط سجلات الـ redo في القاعدة الأساسية.
- تشغيل عمليات استعادة RMAN أو أوامر duplicate لمزامنة القاعدة الاحتياطية.
- تشغيل سلسلة من خطوات التحقق لضمان قدرة القاعدة الاحتياطية على قبول عملية الـ switchover.
يمكن أن يستغرق سير العمل عدة ساعات، خاصة بالنسبة للـ PDBs الكبيرة، وأي خطأ قد يجعل القاعدة الاحتياطية غير قابلة للاستخدام.
ما الذي يقدمه تحديث 23.26.2
يتضمن أحدث إصدار من Oracle AI Database الخطوات المطلوبة ضمن Data Guard Broker. من خلال إصدار أمر ADD PLUGGABLE DATABASE واحد، يقوم الـ broker بما يلي:
- تسجيل الـ PDB الاحتياطية الجديدة مع القاعدة الأساسية.
- نسخ ملفات البيانات اللازمة في الخلفية — دون الحاجة إلى استعادة RMAN أو نسخ الملفات يدويًا.
- إنشاء سجلات الـ standby redo المناسبة، وإضافتها إلى الـ CDB الاحتياطية تلقائيًا.
- ترك الـ PDB في وضع القراءة فقط (READ ONLY)، لتكون جاهزة لعملية physical standby switchover.
كان الأمر المستخدم في الاختبار هو:
DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
SOURCE IS 'amol' AT cdb1
PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";
اختبار من الواقع العملي
قام المؤلف بإنشاء PDB احتياطية باسم AMOL على CDB ثانوية (cdb2) تعكس PDB أساسية على cdb1. أكمل الـ broker العملية فورًا. لم يتم تشغيل استعادة RMAN، ولم تظهر أي عمليات نسخ ملفات يدوية في سجلات نظام التشغيل، وظهرت مجموعات سجلات الـ standby redo في الفهرس (catalog) دون الحاجة إلى أي أوامر ALTER DATABASE.
أدى فتح الـ PDB إلى تحويلها إلى وضع القراءة فقط (READ ONLY)، مما أكد حالة الـ physical-standby الخاصة بها. وأثبت فحص سريع لملفات البيانات أنه قد تم توفيرها على الجانب الاحتياطي. كانت عملية الـ redo apply تعمل بالفعل، وأفاد الـ broker بأن التكوين جاهز لعملية الـ switchover.
التداعيات على مديري قواعد البيانات (DBAs)
تقلل الأتمتة من احتمالية الخطأ البشري وتختصر الوقت من التخطيط إلى مرحلة الاحتياط للإنتاج. يمكن للفرق الآن توفير PDBs احتياطية في دقائق بدلاً من ساعات، وهو أمر قيم للغاية للبيئات التي تقوم بتشغيل خدمات جديدة بشكل متكرر.
المقابل هو اعتماد أكبر على المنطق الداخلي لـ Data Guard Broker. يفضل بعض مديري قواعد البيانات كتابة سكربت لكل خطوة بأنفسهم للحفاظ على تحكم دقيق أو للتكامل مع أدوات مراقبة مخصصة. في الإعدادات المعقدة — مثل الشبكات المتعددة، أو التخزين غير المتجانس، أو تخطيطات الـ redo غير القياسية — قد لا يزال يتعين على المسؤولين التحقق من توافق الإعدادات الافتراضية للـ broker مع سياساتهم.
ما الذي يجب مراقبته لاحقًا
لم تعلن Oracle عن توسعات إضافية لهذه الأتمتة، لكن هذه الخطوة تشير إلى أن الإصدارات المستقبلية قد تنقل المزيد من سير عمل التعافي من الكوارث (DR) في بيئة الـ multitenant إلى الـ broker. ترقب ما يلي:
- دعم أنواع إضافية من الـ standby (مثل الـ logical standby PDBs).
- سجلات موسعة تظهر قرارات الـ broker لأغراض التدقيق.
- فحوصات التوافق مع أدوات النسخ الاحتياطي التابعة لجهات خارجية والتي كانت تعتمد سابقًا على خطوات RMAN يدوية.
إذا كانت مؤسستك تشغل Oracle AI Database في تكوين عالي التوافر (high-availability)، فإن اختبار الأمر الجديد على CDB غير مخصص للإنتاج هو أسرع طريقة لتقييم التأثير.
الخلاصة: يحول Oracle AI Database 23.26.2 إعداد الـ PDB الاحتياطية متعدد الخطوات والمعرض للأخطاء إلى عملية من سطر واحد، مما يوفر تعافيًا من الكوارث أسرع وأكثر موثوقية لبيئات الـ multitenant.