عملية استرجاع الكتل الفاسدة هي من ميزات RMAN، فلو قام مدير قاعدة البيانات بعمل النسخ الاحتياطي عن طريق User-Managed Backup فإن عملية الاسترجاع ستتم على مستوى Data File وذلك لأن User-Managed Restore لا تستطيع عمل Block Recovery. فإذا حدثت مشكلة في كتلة واحدة في Data File فلا بد من عمل استرجاع لكل Data File، وسوف تكون الخطوات كالتالي:

1. وضع Data File في الوضع Offline.
2. عمل Restore لـData File من النسخة الاحتياطية التي أُخذت قبل حدوث المشكلة.
3. عمل Recover لـData File.
4. جلب Data File في الوضع Online.

أما إذا استخدم مدير قاعدة البيانات RMAN فإنه يستطيع تحديد الكتل الفاسدة أثناء عمليات النسخ الاحتياطي. بالطبع إذا استخدمت User-Managed Backup فإنك تستطيع تحديد مشاكل Hardware Corruption وذلك لأن نظام التشغيل يقوم بمعرفة المشكلة عند قراءة الملف أثناء النسخ الاحتياطي ولكنه لا يستطيع اكتشاف Software Corruption، وذلك لأن الملف يظل مقروءاً عن طريق نظام التشغيل.

أما بالنسبة لـRMAN فإنه يقوم بالتحقق من محتويات الكتل أثناء عمليات النسخ الاحتياطي، فلو تم العثور على كتلة فاسدة فإن النسخة الاحتياطية سوف تتوقف لو أردت ذلك، لكن يمكنك مواصلة النسخ الاحتياطي حتى لو تم العثور على كتل فاسدة وذلك من خلال تسجيل عنوين الكتل الفاسدة في الـRepository.

إليك المثال التالي وهو يوضح:

RMAN>run{

Set maxcorrupt for datafile 5 to 50;

Backup datafile 5;

} 

في هذا المثال، قام مدير قاعدة البيانات بعمل نسخ احتياطي لملف البيانات رقم 5، حتى لو وصل عدد الكتل الفاسدة إلى خمسين كتلة. سيتم تخزين عناوين الكتل الفاسدة في الـRepository. ومع ذلك، إذا تجاوز عدد الكتل الفاسدة خمسين كتلة، فسوف تفشل عملية النسخ الاحتياطي.

نستطيع الاستفادة من هذه الخاصية في إكمال عمليات النسخ الاحتياطي حتى لو احتوى النسخ الاحتياطي على بعض الكتل الفاسدة. عموماً، كمدير قاعدة البيانات، يمكنك متابعة الكتل الفاسدة عن طريق V$DATABASE_BLOCK_CORRUPTION، حيث يحتوي على عناوين الكتل التي سببت المشكلة بما في ذلك رقم الملف ورقم الكتلة. عنوان الكتلة في النسخة الاحتياطية يتم تسجيله في V$BACKUP_CORRUPTION إذا كان نوع النسخة الاحتياطية هو BACKUP SET أو في V$COPY_CORRUPTION إذا كان نوع النسخة الاحتياطية هو IMAGE COPY.

في الوضع الطبيعي، لا يتم استخدام الخيار SET MAXCORRUPT، مما يؤدي إلى فشل النسخ الاحتياطي عند العثور على أول Block Corruption. كمدير لقاعدة البيانات، يمكنك تجاهل عملية اختبار الكتل أثناء عمل النسخ الاحتياطي من خلال بعض الخيارات. فإذا أردت مثلاً تجاهل سلامة الكتل من مشاكل Physical Corruption، فما عليك إلا أن تكتب الأمر NOCHECKSUM أثناء النسخ الاحتياطي.

كذلك يمكنك التأكد من سلامة الكتل من المشاكل المنطقية Logical Corruption من خلال الأمر CHECK LOGICAL.

إذا كان مدير قاعدة البيانات ينجز مهامه في النسخ الاحتياطي بواسطة User-Managed Backup، فقد يواجه بعض المشاكل عند استرجاع الكتل الفاسدة. فإذا حدث أن فسدت كتلة واحدة في أحد ملفات Data File فلا بد من استرجاع هذا الملف بأكمله، وذلك لأن User-Managed Backup لا تدعم Block Media Recovery.

أما إذا كان مدير قاعدة البيانات يستخدم الأداة RMAN فإنه يستطيع استرجاع الكتل الفاسدة فقط، مما يقلل الوقت المستغرق في الاسترجاع. كذلك خلال الاسترجاع، تبقى قاعدة البيانات مفتوحة ويظل Data File مفتوحاً، ويمكن للمستخدمين مواصلة عملهم سواء تلك الجلسات التي تحتاج الوصول للكتل التي يتم استرجاعها.

لحظة استرجاع الكتل الفاسدة عن طريق RMAN يتم تزويد RMAN بقائمة الكتل التي نحتاج لاسترجاعها، فتقوم RMAN بالبحث عن هذه الكتل في ملفات النسخ الاحتياطي سواء كان ذلك النسخ الاحتياطي من النوع Backup Set أو النوع Image Copy وتقوم بإرجاعها للملف، ثم تقوم باستخدام ملفات الأرشيف المناسبة لتطبيق التغييرات التي حدثت.

دائماً ما يتم الاسترجاع الكامل Complete Recovery، ولكن يظل المستخدمون يستلمون رسائل الخطأ 01578-ORA مادام يحاولون الوصول للكتل الفاسدة قبل إكمال الاسترجاع.

يتم استرجاع الكتل الفاسدة عبر RMAN عن طريق الأمر BLOCKRECOVER.

RMAN> blockrecover datafile 5 block 5,7;