1 / 6

Motivation for Recovery

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

kolya
Download Presentation

Motivation for 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. Motivation for Recovery • Atomicity: • Transactions may abort (“Rollback”). • Durability: • What if DBMS stops running? (Causes?) • Desired Behavior after system restarts: • T1, T2 & T3 should be durable. • T4 & T5should be aborted (effects not seen). crash! T1 T2 T3 T4 T5

  2. Handling the Buffer Pool • Force every write to disk? • Poor response time. • But provides durability. • Steal buffer-pool frames from uncommitted transactions? • If not, poor throughput. • If so, how can we ensure atomicity? No Steal Steal Force Trivial Desired No Force

  3. Basic Idea: Logging • Record REDO and UNDO information, for every update, in a log. • Sequential writes to log (put it on a separate disk). • Minimal info (difference) written to log, so multiple updates fit in a single log page. • Log: An ordered list of REDO/UNDO actions • Log record contains: <XID, pageID, offset, length, old data, new data> • and additional control information. • The Write-Ahead Logging Protocol: • Must force the log record for an update before the corresponding data page gets to disk. • Must write all log records for a transaction beforecommit.

  4. DB RAM LSNs pageLSNs flushedLSN pageLSN WAL & the Log • Each log record has a unique Log Sequence Number (LSN). • LSNs always increasing. • Each data pagecontains a pageLSN. • The LSN of the most recent log record for an update to that page. • System keeps track of flushedLSN. • The max LSN flushed so far. • WAL:Before a page is written, • pageLSN £ flushedLSN Log records flushed to disk “Log tail” in RAM

  5. Recovery • Three steps: (a la` ARIES) • Starting from a checkpoint: • Analysis: figure out which transactions committed • since the checkpoint, and which failed. • REDOall actions in the log. • UNDO effects of failed transactions.

  6. Summary • Users access the database concurrently, and sometimes there are • crashes. • Transactions are sets of operations that are guaranteed to be atomic. • The DBMS guarantees: Atomicity, Consistency, Isolation, • Durability. • Isolation and consistency are guaranteed via locking: 2-phase • (need special care for deadlocks). • Atomicity and durability are guaranteed by: • Logging • Recovery manager (that uses the log). There are MANY MANY more missing details!

More Related