lect(9) Crash Recovery.pptx

Database Management Systems Crash Recovery Chapter 20 Review: The ACID properties A tomicity: All actions in the Xact happen, or none happen. C onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent. I solation: Execution of one Xact is i...

Database Management Systems Crash Recovery Chapter 20 Review: The ACID properties A tomicity: All actions in the Xact happen, or none happen. C onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent. I solation: Execution of one Xact is isolated from that of other Xacts. D urability: If a Xact commits, its effects persist.  The Recovery Manager guarantees Atomicity & Durability.  Motivation Atomicity: – Transactions may abort (“Rollback”). Durability: – What if DBMS stops running? (Causes?) Motivation cont’d Desired Behavior after system restarts: – T1, T2 & T3 should be durable. – T4 & T5 should be aborted (effects not seen). Handling the Buffer Pool Force every write to disk? – Poor response time. – But provides durability. Steal buffer-pool frames from uncommited Xacts? – If not, poor throughput. – If so, how can we ensure atomicity? Handling the Buffer Pool Cont’d  More on Steal STEAL (why enforcing Atomicity is hard) – To steal frame F: Current page in F (say P) is written to disk; some Xact holds lock on P. What if the Xact with the lock on P aborts? Must remember the old value of P at steal time (to support UNDOing the write to page P).  More on Force NO FORCE (why enforcing Durability is hard) – What if system crashes before a modified page is written to disk? – Write as little as possible, in a convenient place, at commit time,to support REDOing modifications.  Basic Idea: Logging Log: An ordered list of REDO/UNDO actions – Log record contains: – and additional control info (which we’ll see soon).  Write-Ahead Logging (WAL) The Write-Ahead Logging Protocol: 1) Must force the log record for an update before the corresponding data page gets to disk. 2) Must write all log records for a Xact before commit. #1 guarantees Atomicity. #2 guarantees Durability.  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.  WAL & the Log Cont’d System keeps track of flushedLSN. – The max LSN flushed so far. WAL: Before a page is written, – pageLSN ≤ flushedLSN Log Records Possible log record types:  Update Commit Abort End (signifies end of commit or abort) Compensation Log Records (CLRs) – for UNDO actions  Other Log-Related State Transaction Table: – One entry per active Xact. – Contains XID, status (running/commited/aborted), and lastLSN. Dirty Page Table: – One entry per dirty page in buffer pool. – Contains recLSN -- the LSN of the log record which first caused the page to be dirty.