1 / 12

Chapter 17 Recovery System

Chapter 17 Recovery System. Review: The ACID properties. A tomicity: All actions in the transaction happen, or none happen. C onsistency: If each transaction is consistent, and the DB starts consistent, it ends up consistent.

adrianstallings
Download Presentation

Chapter 17 Recovery System

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. Chapter 17Recovery System

  2. Review: The ACID properties • Atomicity: All actions in the transaction happen, or none happen. • Consistency: If each transaction is consistent, and the DB starts consistent, it ends up consistent. • Isolation: Execution of one transaction is isolated from that of other transactions. • Durability: If a transaction commits, its effects persist. • The Recovery Manager guarantees Atomicity & Durability.

  3. Motivation • Atomicity: • Transactions may abort (“Rollback”). • Durability: • What if DBMS stops running? (Why?) • Desired behavior after system restarts: • T1, T2 & T3 should be durable. • T4 & T5should be aborted (effects not seen). crash! T1 T2 T3 T4 T5

  4. Assumptions • Concurrency control is in effect. • Strict 2PL, in particular. Why? • Updates are happening “in place”. • i.e. data is overwritten on (deleted from) the disk. • A simple scheme to guarantee Atomicity & Durability?

  5. Handling the Buffer Pool • Force every write to disk? • Provides durability. • Poor response time; • Steal buffer-pool frames from uncommited transactions? • If not, poor throughput. • If so, how can we ensure atomicity? • How to support atomicity & durability with No Force & Steal? No Steal Steal Trivial Force Desired No Force

  6. More on Steal and Force • STEAL (why enforcing Atomicity is hard) • To steal frame F:Current page in F (say P) is written to disk; some transaction holds lock on P. • What if the transaction with the lock on P aborts? • Must remember the old value of P at steal time (to support UNDO) • NO FORCE(why enforcing Durability is hard) • What if system crashes before a modified page is written to disk?

  7. Log-Based Recovery • Log • Data structure to record the database modifications • A sequence of log records • <TID, Data ID, old value, new value>

  8. Write-Ahead Logging (WAL) 1. Must force the log record for an update before the corresponding data page gets to disk. (stolen page) 2. Must write all log records for a transaction beforecommit. • #1 guarantees Atomicity. • #2 guarantees Durability.

  9. Undo & Redo • Undo: restore to the old values • Redo: set to the new values • What to do for recovery given the following log? What if there is no <Ti, commit>? What to do after writing Ti’s results to the stable storage? • <Ti, start> • <Ti, A, 900, 1000> • <Ti, commit>

  10. Checkpointing • Periodically, the DBMS creates a checkpoint, in order to minimize the time taken to recover in the event of a system crash. Write to log: • begin_checkpointrecord • Freeze the database • Output all records currently in memory • Output all results of committed transactions • end_checkpointrecord • Fuzzy checkpointing

  11. Recovery • Backward analysis to find the latest <checkpoint> • Undo list • Redo list • Undo (backward) • Redo (forward from checkpoint)

  12. Summary of Logging/Recovery • Recovery Manager guarantees Atomicity & Durability. • Use WAL to allow STEAL/NO-FORCE w/o sacrificing correctness. • Checkpointing: A quick way to limit the amount of log to scan on recovery.

More Related