Chapter 23

2. Chapter 23 Database Recovery Techniques تقنيات استعادة قواعد البيانات

3. Chapter 19 Outline Databases Recovery 1. Purpose of Database Recovery 2. Types of Failure 3 . Transaction Log 4 . Data Updates 5. Data Caching 6 . Transaction Roll-back (Undo) and Roll-Forward 7 . Checkpointing 8 . Recovery schemes 10. Recovery in Multidatabase System

4. Database Recoveryاستعادة قاعدة البيانات 1 Purpose of Database Recoveryالغرض من استعادة قاعدة البيانات • To bring the database into the last consistent state, which existed prior to the failure. • لجلب قاعدة البيانات إلى آخر حالة متسقة، والتي كانت موجودة قبل الفشل • To preserve transaction properties (Atomicity, Consistency, Isolation and Durability). • للحفاظ على خصائص المعاملات (الذرية، الاتساق، العزلة والمتانة). • Example: • If the system crashes before a fund transfer transaction completes its execution, then either one or both accounts may have incorrect value. Thus, the database must be restored to the state before the transaction modified any of the accounts. • في حالة تعطل النظام قبل إتمام عملية تحويل الأموال تنفيذه، فإن حساب واحد أو كلا الحسابين قد يكون له قيمة غير صحيحة. وبالتالي، يجب استعادة قاعدة البيانات إلى الدولة قبل المعاملة تعديل أي من الحسابات.

5. Database Recovery 2 Types of Failureأنواع الفشل • The database may become unavailable for use due to قد تصبح قاعدة البيانات غير متاحة للاستخدام بسبب • Transaction failure: Transactions may fail because of incorrect input, deadlock, incorrect synchronization. • فشل المعاملة: قد تفشل المعاملات بسبب إدخال غير صحيح، الجمود، تزامن غير صحيح • System failure: System may fail because of addressing error, application error, operating system fault, RAM failure, etc. • فشل النظام: قد يفشل النظام بسبب معالجة الخطأ، خطأ التطبيق، خطأ نظام التشغيل، فشل ذاكرة الوصول العشوائي، الخ. • Media failure: Disk head crash, power disruption, etc. • فشل الوسائط: تعطل رئيس القرص، انقطاع التيار الكهربائي، الخ.

6. Database Recovery استعادة قاعدة البيانات 3 Transaction Log سجل المعاملات • For recovery from any type of failure data values prior to modification (BFIM - BeFore Image) and the new value after modification (AFIM – AFter Image) are required. • للاسترداد من أي نوع من قيم بيانات الفشل قبل التعديل (بفيم - بيفور صورة) والقيمة الجديدة بعد التعديل (عفيم - أفتر صورة) مطلوبة. • These values and other information is stored in a sequential file called Transaction log. A sample log is given below. Back P and Next P point to the previous and next log records of the same transaction.يتم تخزين هذه القيم والمعلومات الأخرى في ملف متسلسل يسمى سجل المعاملات. ويرد أدناه نموذج سجل. العودة P و التالي P نقطة إلى سجلات السجل السابقة والقادمة من نفس المعاملة.

7. Database Recovery استعادة قاعدة البيانات 4 Data Update 4 تحديث البيانات • Immediate Update: As soon as a data item is modified in cache, the disk copy is updated.تحديث فوري: بمجرد تعديل عنصر البيانات في ذاكرة التخزين المؤقت، يتم تحديث نسخة القرص. • Deferred Update: All modified data items in the cache is written either after a transaction ends its execution or after a fixed number of transactions have completed their execution. • تحديث مؤجل: تتم كتابة كافة عناصر البيانات المعدلة في ذاكرة التخزين المؤقت إما بعد انتهاء المعاملة من تنفيذ أو بعد الانتهاء من عدد ثابت من المعاملات تنفيذها. • Shadow update: The modified version of a data item does not overwrite its disk copy but is written at a separate disk location. • تحديث الظل: النسخة المعدلة من عنصر بيانات لا الكتابة فوق نسخ القرص ولكن مكتوب في موقع قرص منفصل. • In-place update: The disk version of the data item is overwritten by the cache version. • التحديث في مكان: يتم استبدال إصدار القرص من عنصر البيانات بواسطة إصدار ذاكرة التخزين المؤقت.

8. Database Recoveryاستعادة قاعدة البيانات 5 Data Caching5 تخزين البيانات • Data items to be modified are first stored into database cache by the Cache Manager (CM) and after modification they are flushed (written) to the disk. • يتم تخزين عناصر البيانات التي سيتم تعديلها أولا في ذاكرة التخزين المؤقت لقاعدة البيانات من قبل إدارة ذاكرة التخزين المؤقت (سم) وبعد التعديل يتم مسح (مكتوبة) إلى القرص. • The flushing is controlled by Modified and Pin-Unpin bits. يتم التحكم في التنظيف بواسطة تعديل و دبوس دبوس بت. • Pin-Unpin: Instructs the operating system not to flush the data item. • دبوس إزالة التثبيت: يوجه نظام التشغيل عدم مسح عنصر البيانات. • Modified: Indicates the AFIM of the data item. • تعديل: يشير إلى أفيم لعنصر البيانات.

9. Database Recovery استعادة قاعدة البيانات • Transaction Roll-back (Undo) and Roll-Forward (Redo) 6 عملية العودة إلى الوراء (تراجع) و رول إلى الأمام (الإعادة) • To maintain atomicity, a transaction’s operations are redone or undone. • للحفاظ على الذرية، يتم إعادة تشغيل عمليات المعاملة أو التراجع عنها. • Undo: Restore all BFIMs on to disk (Remove all AFIMs). • التراجع: استعادة كافة بفيمس على القرص (إزالة كافة أفيمس). • Redo: Restore all AFIMs on to disk. إعادة: استعادة كافة أفيمس على القرص. • Database recovery is achieved either by performing only Undos or only Redos or by a combination of the two. These operations are recorded in the log as they happen. • يتم تحقيق استعادة قاعدة البيانات إما عن طريق تنفيذ وندوس فقط أو ريدوس فقط أو من خلال مزيج من الاثنين. يتم تسجيل هذه العمليات في السجل عند حدوثها.

10. Database Recoveryاستعادة قاعدة البيانات

11. Database Recovery استعادة قاعدة البيانات

12. Database Recovery استعادة قاعدة البيانات Roll-back: One execution of T1, T2 and T3 as recorded in the log. التراجع: تنفيذ واحد من T1، T2 و T3 كما هو مسجل في السجل.

13. Database Recovery استعادة قاعدة البيانات Write-Ahead Loggingالكتابة قبل التسجيل • When in-place update (immediate or deferred) is used then log is necessary for recovery and it must be available to recovery manager. This is achieved by Write-Ahead Logging (WAL) protocol. WAL states that • عندما يتم استخدام التحديث في مكان (فوري أو مؤجل) ثم سجل ضروري للاسترداد ويجب أن تكون متاحة لمدير الاسترداد. ويتحقق ذلك عن طريق الكتابة قبل التسجيل (وال) البروتوكول. ويقول وال ذلك • For Undo: Before a data item’s AFIM is flushed to the database disk (overwriting the BFIM) its BFIM must be written to the log and the log must be saved on a stable store (log disk). • للتراجع: قبل مسح أفيم عنصر البيانات إلى قرص قاعدة البيانات (الكتابة فوق بفيم) يجب أن يتم كتابة بفيم إلى السجل ويجب حفظ السجل على مخزن ثابت (سجل القرص). • For Redo: Before a transaction executes its commit operation, all its AFIMs must be written to the log and the log must be saved on a stable store. • للإعادة: قبل تنفيذ عملية تنفيذ التزامها، يجب كتابة كافة أفيمس إلى السجل ويجب حفظ السجل على مخزن ثابت.

14. Database Recovery استعادة قاعدة البيانات 7 Checkpointing 7 نقطة تفتيش • Time to time (randomly or under some criteria) the database flushes its buffer to database disk to minimize the task of recovery. The following steps defines a checkpoint operation: • وقت لآخر (بشكل عشوائي أو تحت بعض المعايير) قاعدة البيانات مسح المخزن المؤقت لقرص قاعدة البيانات لتقليل مهمة الانتعاش. وتحدد الخطوات التالية عملية نقطة التفتيش: • Suspend execution of transactions temporarily. تعليق تنفيذ المعاملات مؤقتا. • Force write modified buffer data to disk. فرض كتابة البيانات العازلة تعديلها على القرص. • Write a [checkpoint] record to the log, save the log to disk. اكتب سجل [نقطة تفتيش] إلى السجل، احفظ السجل إلى القرص. • Resume normal transaction execution. استئناف تنفيذ المعاملة العادية. • During recovery redo or undo is required to transactions appearing after [checkpoint] record. أثناء عملية الاسترداد يتم طلب إعادة أو التراجع للمعاملات التي تظهر بعد تسجيل [نقطة تفتيش].

15. Database Recovery استعادة قاعدة البيانات four different ways for handling recovery:أربع طرق مختلفة للتعامل مع الانتعاش: • Steal/No-Force (Undo/Redo) • Steal/Force (Undo/No-redo) • No-Steal/No-Force (Redo/No-undo) • No-Steal/Force (No-undo/No-redo) • سرقة / لا قوة (التراجع / الإعادة) • سرقة / قوة (تراجع / عدم إعادة) • لا سرقة / لا قوة (إعادة / عدم التراجع) • لا سرقة / قوة (لا التراجع / لا إعادة)

16. Database Recoveryاستعادة قاعدة البيانات 8 Recovery Scheme8 خطة الانتعاش • Deferred Update (No Undo/Redo)تحديث مؤجل (لا تراجع / إعادة) • The data update goes as follows:تحديث البيانات يذهب كما يلي: • A set of transactions records their updates in the log. • تسجل مجموعة من المعاملات تحديثاتها في السجل. • At commit point under WAL scheme these updates are saved on database disk. • في نقطة ارتكاب تحت مخطط وال يتم حفظ هذه التحديثات على قرص قاعدة البيانات. • After reboot from a failure the log is used to redo all the transactions affected by this failure. No undo is required because no AFIM is flushed to the disk before a transaction commits. • بعد إعادة التشغيل من الفشل يستخدم السجل لإعادة كافة المعاملات المتأثرة بهذا الفشل. لا يلزم التراجع لأنه لم يتم مسح أفيم إلى القرص قبل إجراء معاملة.

17. Database Recoveryاستعادة قاعدة البيانات • Deferred Update in a single-user systemThere is no concurrent data sharing in a single user system. The data update goes as follows: • تحديث مؤجل في نظام مستخدم واحد؟ لا توجد مشاركة بيانات متزامنة في نظام مستخدم واحد. تحديث البيانات يذهب كما يلي: • A set of transactions records their updates in the log. • تسجل مجموعة من المعاملات تحديثاتها في السجل. • At commit point under WAL scheme these updates are saved on database disk. • في نقطة ارتكاب تحت مخطط وال يتم حفظ هذه التحديثات على قرص قاعدة البيانات. • After reboot from a failure the log is used to redo all the transactions affected by this failure. No undo is required because no AFIM is flushed to the disk before a transaction commits. • بعد إعادة التشغيل من الفشل يستخدم السجل لإعادة كافة المعاملات المتأثرة بهذا الفشل. لا يلزم التراجع لأنه لم يتم مسح أفيم إلى القرص قبل إجراء معاملة.

18. Database Recoveryاستعادة قاعدة البيانات

19. Database Recoveryاستعادة قاعدة البيانات Deferred Update with concurrent users تحديث مؤجل مع المستخدمين المتزامنين • This environment requires some concurrency control mechanism to guarantee isolation property of transactions. In a system recovery transactions which were recorded in the log after the last checkpoint were redone. The recovery manager may scan some of the transactions recorded before the checkpoint to get the AFIMs. • تتطلب هذه البيئة بعض آلية التحكم التزامن لضمان خاصية عزل المعاملات. في معاملات استعادة النظام التي تم تسجيلها في السجل بعد آخر نقطة تفتيش تم إعادة بنائها. قد يقوم مدير الاسترداد بفحص بعض المعاملات المسجلة قبل نقطة التفتيش للحصول على عفيم.

20. Database Recoveryاستعادة قاعدة البيانات

21. Database Recoveryاستعادة قاعدة البيانات Deferred Update with concurrent users تحديث مؤجل مع المستخدمين المتزامنين • Two tables are required for implementing this protocol: • هناك حاجة إلى جدولين لتنفيذ هذا البروتوكول: • Active table: All active transactions are entered in this table. • جدول نشط: يتم ادخال كل المعاملات النشطة في هذا الجدول. • Commit table: Transactions to be committed are entered in this table. • جدول الالتزام: يتم إدخال المعاملات التي سيتم الالتزام بها في هذا الجدول. • During recovery, all transactions of the commit table are redone and all transactions of active tables are ignored since none of their AFIMs reached the database. It is possible that a commit table transaction may be redone twice but this does not create any inconsistency because of a redone is “idempotent”, that is, one redone for an AFIM is equivalent to multiple redone for the same AFIM. • أثناء الاسترداد، يتم إعادة حساب كافة المعاملات من جدول الالتزام ويتم تجاهل كافة المعاملات من الجداول النشطة حيث لم يصل أي من أفيمس قاعدة البيانات. من الممكن أن يتم إعادة ترتيب معاملة جدول مرتين ولكن هذا لا يخلق أي تناقض بسبب إعادة التكرار هو "إدمبوتنت"، أي إعادة إرجاع واحد ل عفيم ما يعادل متعددة ريدون لنفس عفيم.

22. Database Recoveryاستعادة قاعدة البيانات Recovery Techniques Based on Immediate Updateتقنيات الاسترداد بناء على التحديث الفوري • Undo/No-redo Algorithmالتراجع عن / عدم إعادة خوارزمية • In this algorithm AFIMs of a transaction are flushed to the database disk under WAL before it commits. • في هذه الخوارزمية يتم مسح أفيمس من المعاملة إلى قرص قاعدة البيانات تحت وال قبل أن تلتزم. • For this reason the recovery manager undoes all transactions during recovery. • ولهذا السبب يلغي مدير الاسترداد جميع المعاملات أثناء الاسترداد. • No transaction is redone.لا يتم إبطال أي معاملة. • It is possible that a transaction might have completed execution and ready to commit but this transaction is also undone. • من المحتمل أن تكون المعاملة قد أكملت التنفيذ وجاهزة للالتزام ولكن هذه الصفقة يتم التراجع عنها أيضا.

23. Database Recoveryاستعادة قاعدة البيانات Recovery Techniques Based on Immediate Updateتقنيات الاسترداد بناء على التحديث الفوري • Undo/Redo Algorithm (Single-user environment)التراجع / الإعادة الخوارزمية (بيئة المستخدم المفرد) • Recovery schemes of this category apply undo and also redo for recovery. وتطبق خطط الانتعاش من هذه الفئة التراجع وإعادة أيضا للشفاء. • In a single-user environment no concurrency control is required but a log is maintained under WAL. في بيئة مستخدم واحد لا يلزم التحكم التزامن ولكن يتم الاحتفاظ سجل تحت وال. • Note that at any time there will be one transaction in the system and it will be either in the commit table or in the active table. • The recovery manager performs:يقوم مدير الاسترداد بما يلي: • Undo of a transaction if it is in the active table. • التراجع عن معاملة إذا كان في الجدول النشط. • Redo of a transaction if it is in the commit table. • إعادة المعاملة إذا كانت في جدول الالتزام

24. Database Recoveryاستعادة قاعدة البيانات Recovery Techniques Based on Immediate Updateتقنيات الاسترداد بناء على التحديث الفوري • Undo/Redo Algorithm (Concurrent execution)التراجع / إعادة الخوارزمية (التنفيذ المتزامن) • Recovery schemes of this category applies undo and also redo to recover the database from failure.تنطبق أنظمة الاسترداد لهذه الفئة على التراجع وإعادة أيضا لاستعادة قاعدة البيانات من الفشل. • In concurrent execution environment a concurrency control is required and log is maintained under WAL.في بيئة التنفيذ المتزامن مطلوب مراقبة التزامن ويتم الاحتفاظ سجل تحت وال. • Commit table records transactions to be committed and active table records active transactions. To minimize the work of the recovery manager checkpointing is used. • يسجل جدول الالتزام المعاملات التي يتم الالتزام بها وسجلات الجدول النشطة المعاملات النشطة. لتقليل عمل مدير التحقق من الانتعاش يستخدم. • The recovery performs:أداء الانتعاش: • Undo of a transaction if it is in the active table.التراجع عن معاملة إذا كان في الجدول النشط. • Redo of a transaction if it is in the commit table.إعادة المعاملة إذا كانت في جدول الالتزام.

25. Database Recoveryاستعادة قاعدة البيانات Shadow Pagingالظل الترحيل • The AFIM does not overwrite its BFIM but recorded at another place on the disk. Thus, at any time a data item has AFIM and BFIM (Shadow copy of the data item) at two different places on the disk. • و أفيم لا الكتابة فوق بفيم ولكن سجلت في مكان آخر على القرص. وهكذا، في أي وقت عنصر البيانات لديها عفيم و بفيم (نسخة الظل من عنصر البيانات) في مكانين مختلفين على القرص. X and Y: Shadow copies of data items X' and Y': Current copies of data items النسخ الحالية لبنود البيانات

26. Database Recoveryاستعادة قاعدة البيانات Shadow Paging الظل الترحيل • To manage access of data items by concurrent transactions two directories (current and shadow) are used. • لإدارة الوصول إلى عناصر البيانات من خلال المعاملات المتزامنة اثنين من الدلائل (الحالية والظل) وتستخدم. • The directory arrangement is illustrated below. Here a page is a data item. • ويرد ترتيب الدليل أدناه. في ما يلي صفحة هي عنصر بيانات.

27. Database Recoveryاستعادة قاعدة البيانات The ARIES Recovery Algorithm خوارزمية استرداد أريس • The ARIES Recovery Algorithm is based on:ويستند خوارزمية استرداد أريس على: • WAL (Write Ahead Logging) وال (ورايت أهيد لوجينغ) • Repeating history during redo: تكرار التاريخ أثناء الإعادة: • ARIES will retrace all actions of the database system prior to the crash to reconstruct the database state when the crash occurred. • سوف أريس تعقب كافة الإجراءات من نظام قاعدة البيانات قبل وقوع الحادث لإعادة بناء حالة قاعدة البيانات عند وقوع الحادث. • Logging changes during undo:تسجيل التغييرات أثناء التراجع: • It will prevent ARIES from repeating the completed undo operations if a failure occurs during recovery, which causes a restart of the recovery process. • وسوف يمنع أريس من تكرار عمليات التراجع المكتملة إذا حدث فشل أثناء الاسترداد، مما يؤدي إلى إعادة تشغيل عملية الاسترداد.

28. Database Recoveryاستعادة قاعدة البيانات 10 Recovery in multidatabase system10 الانتعاش في نظام قواعد البيانات المتعددة • A multidatabase system is a special distributed database system where one node may be running relational database system under UNIX, another may be running object-oriented system under Windows and so on. • نظام متعدد قواعد البيانات هو نظام قاعدة بيانات موزعة خاص حيث عقدة واحدة قد يكون تشغيل نظام قاعدة البيانات العلائقية تحت أونيكس، آخر قد يكون تشغيل نظام كائن المنحى تحت ويندوز وهلم جرا. • A transaction may run in a distributed fashion at multiple nodes.قد يتم تشغيل الصفقة بطريقة موزعة في عقد متعددة. • In this execution scenario the transaction commits only when all these multiple nodes agree to commit individually the part of the transaction they were executing. في سيناريو التنفيذ هذا لا تتم المعاملات إلا عندما توافق كل هذه العقد المتعددة على الالتزام بشكل فردي بجزء المعاملة التي كانت تنفذها. • This commit scheme is referred to as “two-phase commit” (2PC). ويشار إلى هذا المخطط الالتزام ب "الالتزام على مرحلتين" (2PC). • If any one of these nodes fails or cannot commit the part of the transaction, then the transaction is aborted. إذا فشل أي من هذه العقد أو لا يمكن أن يرتكب جزء من المعاملة، ثم يتم إحباط المعاملة. • Each node recovers the transaction under its own recovery protocol. • تسترد كل عقدة المعاملة بموجب بروتوكول الاسترداد الخاص بها.

29. Summaryملخص • Databases Recovery استعادة قواعد البيانات • Types of Failure أنواع الفشل • Transaction Log سجل المعاملات • Data Updates تحديثات البيانات • Data Caching التخزين المؤقت للبيانات • Transaction Roll-back (Undo) and Roll-Forward • المعاملات لفة العودة (تراجع) و لفة إلى الأمام • Checkpointing التدقيق والفحص • Recovery schemesخطط الاسترداد • ARIES Recovery Scheme أريز، إسترداد، سشيم • Recovery in Multidatabase Systemالانتعاش في نظام قواعد البيانات المتعددة