هل فكرت يوما ماذا ستفعل لو حذفت مستخدم بالخطأ؟ الجواب بكل بساطة هو أن أقوم باستعادة قاعدة البيانات Recovery من نسخة احتياطية Backup.

هذا الحل صحيح ولكنه مكلف من حيث الوقت خاصة إذا كانت قاعدة البيانات كبيرة. فاستعادة أحجام كبيرة من الملفات لابد وأن تكون مكلفة من حيث الوقت.

ما الحل إذن؟ الحل هو Flashback Database.

Flashback Database هو إرجاع قاعدة البيانات إلى نقطة زمنية محددة في الماضي، بحيث تكون كل التعديلات التي حدثت في قاعدة البيانات من تلك النقطة حتى الآن وكأنها لم تحدث قط. نستفيد من Flashback Database في حالة وجود أخطاء منطقية، مثل قيام مسؤول قاعدة البيانات بحذف مستخدم عن طريق الخطأ أو عمل Truncate Table، أما في حالة وجود أخطاء مادية مثل فقدان Data File أو ملفات أخرى، فلا يمكننا الاستفادة من Flashback Database وكل ما يمكننا فعله هو استعادة الملفات من النسخة الاحتياطية بالطريقة التقليدية.

عملية Flashback Database هي عملية سريعة جدًا لإرجاع قاعدة البيانات إلى فترة زمنية في الماضي مقارنة بعملية الاستعادة من ملفات النسخ الاحتياطي بالطريقة التقليدية. يرجع ذلك إلى أننا لا نحتاج إلى استعادة ملفات النسخ الاحتياطي لقاعدة البيانات. في اللحظة التي يتم فيها تشغيلEnable Flashback Database ، يتم إنشاء Background Process  تسمى Recovery Writer (RVWR).

يتم تخصيص جزء من ذاكرة SGA يسمى Flashback Buffer، ويتم تخصيص جزء من القرص  ﻟلFlashback logs. يكون هذا الجزء دائمًا في ﺍلFlash Recovery Area.

السيناريو هو أن كل Block  تم تعديله في قاعدة البيانات يتم إرسالها إلى Flash Buffer. بعد ذلك، يضع RVWR هذه ﺍلBlocks من Flashback Buffer إلى Flashback Logs.

هذا السيناريو مشابه جدًا لسيناريو Redo Log Buffer و Redo Log Files، لكن الاختلاف هو أنه لا تتم كتابة جميع التعديلات في Flashback Buffer كما هو الحال مع Redo Log Buffer.

لكن Complete Block Images وﺍلFlashback Loges  لا يتم أرشفتها كما هو الحال مع Redo Log Files.

كما ذكرت، لا تتم كتابة جميع التعديلات في Flashback Buffer. ولكن Complete Block Images، لذلك هناك العديد من التعديلات التي تحدث ولا يتم كتابتها مباشرة في Flashback Buffer.

ولكنها تتأخر وقد تحدث تعديلات أخرى قبل كتابتها في Flashback Buffer، ما أعنيه هو أنه قد يتم كتابة Complete Block  وتحتوي على مجموعة مختلفة من التعديلات التي حدثت

في أوقات مختلفة، لذا فإن عملية قاعدة بيانات Flashback لفترة زمنية محددة صعبة للغاية، لذا فإن ﺍلFlashback Database تحتاج إلى أن تكون قاعدة البيانات في Archive Log Mode

لأن الأرشيف يحتوي على جميع تفاصيل التعديلات التي حدثت في قاعدة البيانات على عكس Flashback Logs  لذا

يمكن لFlashback Logs مع ﺍلArchive Logs أن تجعل عملية ﺍلFlashback Database . ناجحة.

لتهيئة Flashback Database، اتبع الخطوات التالية:-

1 - تأكد من تشغيل قاعدة البيانات في وضع Archive log mode.

في الفصول السابقة، تحدثنا عن تشغيل قاعدة البيانات لملفين على الأقل من Redo Log Files، وهي ملفات تحتوي على التعديلات التي أجريت على قاعدة البيانات.

تكتب LGWR Background Process  التعديلات في Log Redo Buffer وتضعها في ﺍلRedo Log Files . تتم عملية الكتابة بشكل دوري بين ﺍلRedo Logs ويتم إعادة الكتابة في ﺍلRedo Logs مما يؤدي إلى فقدان البيانات الموجودة بها لذا الحل هو تشغيل قاعدة البيانات في وضع Archive Log Mode  حيث يتم إنشاء Background Process  جديد يسمى ARCn يقوم بعمل نسخ من ﺍلRedo Log Files حتى لا نفقد البيانات الموجودة في هذه الملفات والتي نعتمد عليها في عملية الاستعادة Recovery وبدونها تفشل عملية ﺍلRecovery.

لمعرفة هل تعمل قاعدة البيانات في وضع Archive Log Mode أم لا؟

SELECT LOG_MODE FROM V$DATABASE;

لإعداد قاعدة البيانات في وضع Archive Log، نقوم بالخطوات التالية:

أ- تحديد المكان الذي سنضع فيه الأرشيف باستخدام المتغير LOG_ARCHIVE_DEST، مع الأخذ في الاعتبار أنه يمكن تحديد اتجاهات مختلفة باستخدام المتغيرات LOG_ARCHIVE_DEST_n.

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=D:\ARCHIVE\’ SCOPE=SPFILE;

كما ذكرت سابقا يمكن تحديد اتجاهات اخرى للأرشيف وتكوين متغيرات اخرى ولكنها ليست ضرورية مثلا LOG_ARCHIVE_FORMAT هذا المتغير لتحديد الصيغة التي يخرج بها ملف الأرشيف.

ب- اغلق قاعدة البيانات وافتحها في وضع Mount ثم قم بتنفيذ الامر ALTER DATABASE ARCHIVELOG.

ALTER DATABASE ARCHIVELOG;

الآن يتم تشغيل قاعدة البيانات في ARCHIVELOG MODE .

يمكنك أيضًا الاستعلام عن تشغيل ARCHIVELOG MODE  من خلال:

SELECT ARCHIVER FROM V$INSTANCE;

لحظه عمل SWITCH LOGFILE. يتم نسخ ملف ﺍلREDO LOG FILE  إلى الأرشيف.

ALTER SYSTEM SWITCH LOGFILE;

يمكنك أيضًا الاستعلام عن ملفات الأرشيف.

SELECT NAME FROM V$ARCHIVED_LOG;

 2-: تهيئة الFlash Recovery Area:

لقد ذكرت سابقًا أن ﺍلFlashback Logs تتم إدارتها فقط في ﺍلFlash Recovery Area ، وهي مكان مخصص بواسطة المتغير DB_RECOVERY_FILE_DEST، ويتم تحديد حجم هذا المكان المخصص

بواسطة هذا المتغير DB_RECOVERY_FILE_DEST_SIZE، لذا لتهيئة ﺍل Flash Area Recovery، نحتاج إلى تهيئة المتغيرين (DB_RECOVERY_FILE_DEST_SIZE & DB_RECOVERY_FILE_DEST).

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST=’D:\ORACLE\PRODUCT\10.1.0\ FLASH_RECOVERY_AREA;

 لقد قمنا بتهيئة ﺍلFlash Recovery Area ويمكننا التحقق من ذلك من خلال مراجعة المتغيرات (DB_RECOVERY_FILE_DEST & DB_RECOVERY_FILE_DEST_SIZE).

SHOW PARAMETER DB_RECOVERY_FILE_DEST;

3 - تحديد فترة الاحتفاظ بالFlashback Log:

هذه الفترة قبل استخدامه وإعادة كتابته مرة أخرى. يتم تحديد ذلك من خلال المتغير DB_FLASHBACK_RETENTION_TARGET، وهو وقت الاحتفاظ بالدقائق بالدقائق. و القيمة الافتراضية

هي ان يتم الاحتفاظ ليوم واحد.

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=1440;

 4 - أغلق قاعدة البيانات وافتحها في وضع Mount:

ثم قم بنهيئة Flashback باستخدام الأمر ALTER DATABASE FLASHBACK ON

ALTER DATABASE FLASHBACK ON;

وبهذا نكون قد انتهينا من تهيئة Flashback.

وللتأكد من تهيئة Flashback، نقوم بتشغيل الاستعلام التالي:

SELECT FLASHBACK_ON FROM V$DATABASE;

لمراقبة  ﺍلFlashback

SELECT * FROM V$FLASHBACK_DATABASE_LOG;

لكي نعرف كيفية استخدام ﺍلFlashback Database، دعونا نتابع هذا السيناريو معًا:

1- قام مسؤول قاعدة البيانات بحذف المستخدم TEST عن طريق الخطأ.

DROP USER TEST CASCADE;

2- قم بإغلاق قاعدة البيانات وافتحها في وضع Mount ، ومن ثم عمل Flashback Database إلى الوقت 01-06-08:12-55-54، وهو الوقت قبل حذف المستخدم TEST.

FLASHBACK DATABASE TO TIMESTAMP TO_TIMESTAMP('17-06-08:12-55-54','DD-MM-YY:HH٤٢- MI-SS');

3- افتح قاعدة البيانات في وضع Resetlogs.

ALTER DATABASE OPEN RESETLOGS;

4- وأخيرًا، دعونا نتأكد من وجود المستخدم TEST.

SELECT USERNAME FROM DBA_USERS WHERE USERNAME='TEST';

ولكن إذا لم نعرف مثلا وقت حذف المستخدم TEST فلا حل أمامنا سوى التخمين ثم فتح قاعدة البيانات في وضع Read Only والتأكد من إمكانية الاستعادة وقد نلجأ إلى إغلاق قاعدة البيانات وفتحها مرة أخرى ثم إعادة ﺍلFlashback Database في وقت آخر ولا نفتح قاعدة البيانات مباشرة في وضع Resetlogs لأن خيار Restlogs يعيد تهيئة السجل مرة أخرى ويبدأ بأخذ القيمة (001) مرة أخرى.