Presentation is loading. Please wait.

Presentation is loading. Please wait.

Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 2) Academic Year 2014 Spring.

Similar presentations


Presentation on theme: "Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 2) Academic Year 2014 Spring."— Presentation transcript:

1 Academic Year 2014 Spring

2 MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 2) Academic Year 2014 Spring

3 Recovery – System Failure:  Ensure that log is written to disk before changes (updates) are made to disk  System Failure will affect all transactions currently in progress but not database itself  System recovery is carried out as part of system’s restart procedure  There are three main techniques used for recovery from System Failures  Deferred Update  Immediate Update  Shadow Paging

4 Key Points about System Recovery:  System Failure results in lost of contents of main memory (database buffer).  Any transaction in progress at time of failure can no longer be successfully completed. So these transactions must be undone (rollback) when system restarts.  At restart time, it might also be necessary to redo certain transactions which did successfully complete before failure but did not manage to get their updates transferred from database buffers to database itself.

5 Checkpoint & Checkpoint Record:  Log file contains Checkpoint Records  At certain prescribed intervals system takes a Checkpoint. At Checkpoint, the system:  Physically writes (force writing) contents of database buffers to physical database  Physically writes a special checkpoint record to log  Checkpoint record gives a list of all transactions in progress at time checkpoint was taken

6 Deferred Update:  Under this Recovery Protocol, updates (changes) are not written to database until after transaction has reached its Commit point  If a transaction fails before reaching its commit point, Database will not be modified, nothing needs to be UNDONE  If system failure occurs after commit point, it may still be necessary to REDO updates of committed transaction as its effect may not have reached database

7 Immediate Update (1):  Under this Recovery Protocol, updates (changes) are written to database immediately without waiting to reach Commit point  Following a failure, system should UNDO updates made by transaction which had not committed at time of failure  It may still be necessary to REDO updates of committed transactions

8 Immediate Update (2): Key operations  Check most recent checkpoint record when recovering from system crash  REDO all work done by transactions which completed successfully before crash  UNDO all work done by transactions which started but did not complete before crash

9 Immediate Update (3): General procedure – an outline  On restart find checkpoint record from restart file  Start with UNDO list and REDO list  Set UNDO equal to list of all transactions given in most recent checkpoint record and set REDO to empty  Search forward through log starting at checkpoint  If a Begin-Transaction is found, put that transaction in UNDO-list

10 Immediate Update (4):  If commit is found, move that transaction from UNDO -list to REDO -list  At end of log, REDO -list and UNDO -list are completed  Work backward through log undoing all transaction in UNDO -list  Work forward through log redoing all transaction in REDO -list

11 Example – Immediate Update:

12

13  Summary of operation for example  After forward search of log  Therefore, work backward to UNDO T3 and T5  Then work forward to REDO T2 and T4 Example – Immediate Update:

14 Immediate Update – Summary:

15  Consider various transactions in case  Question  Which transaction(s) need to be undone, redone or done nothing Immediate Update – Summary:

16  Answer  REDO–T2, T4  UNDO– T3, T5  Do nothing– T1 Immediate Update – Summary:

17  This is an alternative scheme to log based recovery schemes  DBMS keeps more than one copy of data item on disk  This is in contrast to one place update approach where DBMS keeps only one copy of each data item on disk. Consequently, each time a new value of data item is written to disk, its old value is destroyed (replaced) Shadow Paging:

18  Shadow Copies  We can choose to keep more than one copy of data item so that new value of data item may be written to disk without destroying old value. Old versions are called shadow copies  Two Page Tables (Directories)  A Page Table (directory) is used pointing at data items  Each entry in page table gives name and position of each data item in disk Shadow Paging – Key Points:

19  Shadow Copies  We can choose to keep more than one copy of data item so that new value of data item may be written to disk without destroying old value. Old versions are called shadow copies We need to keep two page tables to reflect shadow paging Therefore, each page table defines a different state of database; before and after updates Current Page Table & Shadow Page Table Current Page Table: New values Shadow Page Table: Old values Shadow Paging – Key Points (continued) :

20 Thank you!!! Questions are WELCOME Academic Year 2014 Spring


Download ppt "Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 2) Academic Year 2014 Spring."

Similar presentations


Ads by Google