1 / 35

Transactions and Recovery

Transactions and Recovery. Checkpointing Souhad Daraghma. INTRODUCTION. Checkpointing. Checkpointing. 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:

tana
Download Presentation

Transactions and Recovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Transactions and Recovery Checkpointing SouhadDaraghma

  2. INTRODUCTION Transactions and Recovery

  3. Transactions and Recovery

  4. Transactions and Recovery

  5. Transactions and Recovery

  6. Transactions and Recovery

  7. Transactions and Recovery

  8. Transactions and Recovery

  9. Transactions and Recovery

  10. Transactions and Recovery

  11. Transactions and Recovery

  12. Transactions and Recovery

  13. Transactions and Recovery

  14. Transactions and Recovery

  15. Transactions and Recovery

  16. Transactions and Recovery

  17. Checkpointing Transactions and Recovery

  18. Checkpointing • 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.

  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. Recovery in a concurrent users environment.

  20. 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 modifications 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 a modification is equivalent to multiple redone for the same modification.

  21. Types of Transactions T1 T2 T3 T4 T5 Last Checkpoint System Failure Transactions and Recovery

  22. Any transaction that was running at the time of failure needs to be undone and restarted Any transactions that committed since the last checkpoint need to be redone Transactions of type T1 need no recovery Transactions of type T3 or T5 need to be undone and restarted Transactions of type T2 or T4 need to be redone System Recovery Transactions and Recovery

  23. Transaction Recovery UNDO and REDO: lists of transactions UNDO = all transactions running at the last checkpoint REDO = empty For each entry in the log, starting at the last checkpoint If a START TRANSACTION entry is found for T Add T to UNDO If a COMMIT entry is found for T Move T from UNDO to REDO Transactions and Recovery

  24. Transaction Recovery T1 T2 T3 T4 T5 Checkpoint Failure UNDO: T2, T3 Last Checkpoint Active transactions: T2, T3 REDO: Transactions and Recovery

  25. Transaction Recovery T1 T2 T3 T4 T5 Checkpoint Failure UNDO: T2, T3, T4 T4 Begins Add T4 to UNDO REDO: Transactions and Recovery

  26. Transaction Recovery T1 T2 T3 T4 T5 Checkpoint Failure UNDO: T2, T3, T4, T5 T5 begins Add T5 to UNDO REDO: Transactions and Recovery

  27. Transaction Recovery T1 T2 T3 T4 T5 Checkpoint Failure UNDO: T3, T4, T5 T2 Commits Move T2 to REDO REDO: T2 Transactions and Recovery

  28. Transaction Recovery T1 T2 T3 T4 T5 Checkpoint Failure UNDO: T3, T5 T4 Commits Move T4 to REDO REDO: T2, T4 Transactions and Recovery

  29. Backwards recovery We need to undo some transactions Working backwards through the log we undo any operation by a transaction on the UNDO list This returns the database to a consistent state Forwards recovery Some transactions need to be redone Working forwards through the log we redo any operation by a transaction on the REDO list This brings the database up to date Forwards and Backwards Transactions and Recovery

  30. Examples Transactions and Recovery

  31. Recovery Techniques Based on Deferred Update FIGURE 19.4 An example of recovery using deferred update with concurrent transactions. (a) The READ and WRITE operations of four transactions. (b) System log at the point of crash.

  32. Recovery Techniques Based on Immediate Update [start_transaction, T1] [write_item, T1,D, 20, 25] [commit,T1] [checkpoint] [start_transaction, T2 ] [write_item, T2,B, 12,18] [start_transaction, T4 ] [write_item, T4,D, 25,15] [start_transaction, T3] [write_item, T3,C, 30,40] [write_item, T4,A, 30, 20] [commit,T4] [write_item, T2,D, 15, 25] <-----system crash FIGURE 19.7 An example schedule and its corresponding log.

  33. System failures are not too severe Only information since the last checkpoint is affected This can be recovered from the transaction log Media failures (disk crashes etc) are more serious The data stored to disk is damaged The transaction log itself may be damaged Media Failures Transactions and Recovery

  34. Backups are needed to recover from media failure The transaction log and entire contents of the database is written to secondary storage (often tape) Time consuming, and often requires down time Backups frequency Frequent enough that little information is lost Not so frequent as to cause problems Every day (night) is common Backup storage Backups Transactions and Recovery

  35. Restore the database from the last backup Use the transaction log to redo any changes made since the last backup If the transaction log is damaged you can’t do step 2 Store the log on a separate physical device to the database The risk of losing both is then reduced Recovery from Media Failure Transactions and Recovery

More Related