Presentation is loading. Please wait.

Presentation is loading. Please wait.

Motivation for Recovery Atomicity: –Transactions may abort (“Rollback”). Durability: –What if DBMS stops running? (Causes?) crash! v Desired Behavior after.

Similar presentations


Presentation on theme: "Motivation for Recovery Atomicity: –Transactions may abort (“Rollback”). Durability: –What if DBMS stops running? (Causes?) crash! v Desired Behavior after."— Presentation transcript:

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

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: –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 before commit.

4 WAL & the Log Each log record has a unique Log Sequence Number (LSN). –LSNs always increasing. Each data page contains 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 LSNs DB pageLSNs RAM flushedLSN pageLSN 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. REDO all 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!


Download ppt "Motivation for Recovery Atomicity: –Transactions may abort (“Rollback”). Durability: –What if DBMS stops running? (Causes?) crash! v Desired Behavior after."

Similar presentations


Ads by Google