UNIT 9 Crash Recovery Based on: Text: Chapter 18 Skip: Section 18.7 and second half of 18.8
Learning Goals Describe the steal and force buffer policies and explain how they affect a transaction s properties Describe the three phases of the ARIES crash recovery algorithm Describe the actions taken by ARIES when a transaction updates a page, aborts or commits Given a schedule with a set of actions, show the log that would be produced by these actions Unit 8 2
Review: Transaction Properties Atomicity: Either all actions in the transactions occur, or none occurs. Consistency: If each transaction is consistent, and the DB starts in a consistent state, then the DB ends up being consistent. Isolation: The execution of one transaction is isolated from that of other transactions. Durability: If a transaction commits, then its effects persist. The Recovery Manager guarantees Atomicity & Durability. Unit 8 3
Enforcing Atomicity & Durability Atomicity: Transactions may abort ; Need to rollback changes Durability: What if DBMS stops running? Need to remember committed changes. T1 T2 T3 T4 T5 crash! Desired behavior after system restarts: T1, T2, & T3 should be durable. T4 & T5 should be aborted (effects not seen) Unit 8 4
Handling the Buffer Pool Transactions modify pages that are in memory buffers When updated pages should be written on the disk? Many choices: steal approach: when system needs the page, write it on the disk even if the transactions that changed it are still active no-steal approach: keep a page in memory if an active transaction updated it force approach: when a transaction commits write all pages modified by it no-force approach: when a transaction commits no need to write all pages modified by it; pages are written only when their buffers are needed Unit 8 5
No Force Force Steal and No Force Buffer Management Policies Most systems use steal and noforce Steal: Enforcing atomicity is hard To steal page P, written by the active transaction T, must write it to disk What if transaction T aborts? Must remember the old value of P. No Force: Enforcing Durability is hard What if system crashes before a page modified by a committed transaction is written to disk? Need to keep information to do the changes when system starts again. No Steal Trivial for A&D Steal Difficult for A&D Unit 8 6
Log Based Recovery Methods Use a log and write any database change first in the log Use the log to Undo or Redo transactions Log should record the old value and the new value for a database item to undo a transaction use the old values to redo a transaction use the new values Many algorithms for logging based recovery exist We ll study the ARIES algorithm simple, log-based recovery algorithm works well with steal and no-force. handle crashes during recovery Unit 8 7
ARIES Crash Recovery Algorithm There are 3 phases in the ARIES recovery algorithm: 1. Analysis: Start from some point in the log and scan it forward to identify: 2. Redo: all transactions that were active all dirty pages in the buffer pool at the time of the crash Start from some point in the log and repeat all actions, up to the crash point restores database state before crash 3. Undo: Undo the actions of transactions that did not commit Work backwards in the log. Unit 8 8
The Log (or Trail or Journal) A file of action records stored in stable storage. Records the sequence of action on the DB Most recent page(s) is(are) in memory, called the log tail Each log record has a unique Log Sequence Number (LSN) LSN is always increasing Each data page contains a pagelsn It s the LSN of the most recent log record that made a change to that page Log records from the same transaction form a backlinked linked list Every log record has: transid, prevlsn, type Log records flushed to disk pagelsn Log tail in RAM Unit 8 9
Log Records LogRecord fields: update records only prevlsn transid type pageid length offset before-image after-image Possible log record types: Update Commit Abort End (signifies end of commit or abort) Compensation Log Records (CLRs) for UNDO actions before and after image are the data before and after the update. Unit 8 10
When Log Records are Created Update : Inserted when a transaction modifies a page. Contains all the fields. pagelsn of that page is set to the LSN of the log record for this update. Commit : Inserted when a transaction commits The log is force-written to stable storage. Abort : Created when a transaction is aborted End : Created when a transaction has completed all the work (after commit or abort) Compensation (CLR) : Inserted before an action described by an update log record is undone. It happens during aborting or recovery. Contains a field undonextlsn with the LSN of the next log record that is to be undone. CLR s are never undone. Unit 8 11
Other Log-Related Structures Transaction manager also maintains the following tables Transaction Table: Maintained by transaction manager Has one entry per active transaction Contains tranid, status (running/committed/aborted), and lastlsn (LSN of most recent log record for it) A transaction is removed from the table when an end record is inserted in the log Dirty Page Table: Maintained by buffer manager Has one entry per dirty page in buffer pool Contains reclsn -- the LSN of the log record which first updated the page Entry is removed when page is written to the disk Both tables must be reconstructed during recovery. Unit 8 12
Transaction and Dirty Pages Table Example pageid reclsn p300 p500 L902 L901 DIRTY PAGE TABLE LOG p800 L900 LSN prevlsn transid type pageid length offset before-i after-i L900 L901 L902 L903 0 t100 update p800 4 20 AAAA BBBB 0 t200 update p500 3 50 CCC ABC L900 t100 update p300 4 80 ABCD DDDD L901 t200 update p800 4 20 BBBB EEEE transid status lastlsn t100 U L902 t200 U L903 TRANSACTON TABLE Unit 8 13
Write-Ahead Logging (WAL) Write-Ahead Logging Protocol: 1. Must force the writing out of all log records that updated a page before the corresponding data page is written on the disk 2. Must write all log records for a transaction before commit #1 guarantees Atomicity #2 guarantees Durability Following WAL, when the current transaction is committed the log tail is forced to stable storage, even when a no-force approach is used. Note: Force/no-force is a strategy for writing data pages to disk. WAL is a strategy for writing the log pages to stable storage. Unit 8 14
Checkpoints Periodically, the DBMS creates a checkpoint, in order to mark where to start the recovery in the event of a system crash. A checkpoint writes to log: begin_checkpoint record: Indicates when checkpoint began end_checkpoint record: Contains current transaction table and dirty page table. This is a `fuzzy checkpoint : transactions continue to run; so these tables are accurate only as of the time of the begin_checkpoint record No attempt to force dirty pages to disk Store LSN of checkpoint record in a safe place (master record). When system starts after a crash locates the most recent checkpoint restores transaction table and dirty page table from there. Unit 8 15
The Big Picture: What s Stored Where LOG log records prevlsn transid type pageid length offset before-image after-image DB data pages each with a pagelsn master record RAM transaction table transid lastlsn status dirty page table reclsn Unit 8 16
Normal Execution of a transaction A transaction is a Series of reads & writes, followed by commit or abort Transactions are executed concurrently following a CC protocol like 2PL or timestamp-based CC STEAL, NO-FORCE buffer management is used Write-Ahead Logging is used Unit 8 17
Actions When a Transaction Aborts We want to play back the log in reverse order, UNDOing updates Get lastlsn of transaction from transaction table Follow chain of log records backward via the prevlsn field Before starting UNDO, write an Abort log record for recovering from crash during UNDO Unit 8 18
Abort, cont. UNDO all the actions performed by the transaction Before restoring old value of a page, write a CLR: CLR has one extra field: undonextlsn Points to the next LSN to undo (i.e. the prevlsn of the record we re currently undoing). CLRs are never undone but they might be redone during REDO phase At end of UNDO, write an End log record for the transaction Unit 8 19
Actions when a Transaction Commits Write a Commit record to log for this transaction All log records up to transaction s lastlsn are flushed Note that log flushes are sequential, synchronous writes to disk. Many log records per log page When all log records are written to stable storage, write an End record to log for this transaction Unit 8 20
Crash Recovery: Big Picture Oldest log rec. of transactions active at crash Smallest reclsn in dirty page table after Analysis Last checkpoint CRASH LOG A R U Start from a checkpoint (found via master record) Three phases: Analysis: Figure out which transactions committed or failed since checkpoint REDO all actions (repeat history) UNDO effects of failed transactions Unit 8 21
Other Recovery Algorithms Most popular are like ARIES: maintain a log use WAL Their Redo phase is different: they don t repeat the whole history they only redo the transactions that were not active at the crash Advantages of ARIES supports fine and multi granularity locks supports logical operation modifications, than just byte modifications. Unit 8 22
Summary of Logging/Recovery Recovery Manager guarantees Atomicity & Durability. Use WAL to allow STEAL/NO-FORCE without sacrificing correctness. LSNs identify log records; linked into backwards chains per transaction (via prevlsn). pagelsn allows comparison of data page and log records. Unit 8 23
Summary, cont. Checkpointing: A quick way to limit the amount of log to scan on recovery. Recovery works in 3 phases: Analysis: Forward from checkpoint Redo: Forward from oldest reclsn Undo: Backward from end to first LSN of oldest transaction alive at crash Redo repeats history : Simplifies the logic! Undo, write CLRs. Recovery algorithm works well with repeated crashes during recovery. Unit 8 24