Why Is This Important? Needed for achieving atomicity and durability - PDF document

Why Is This Important?  Needed for achieving atomicity and durability  Need to abort transactions or restart them Crash Recovery  Need to recover from crashes  Crash recovery algorithms had major impact beyond Chapter 18 databases  Algorithms are interesting in their own right  Logging for crash recovery has significant impact on DBMS performance 1 2 Motivation Handling the Buffer Pool  Atomicity: Transactions may abort (“Rollback”).  Assumption: data on disk is durable  Durability: What if DBMS stops running? (Causes?) No Steal Steal  Force every write to disk?  Desired Behavior after system restarts:  Poor response time. Force Trivial  T1, T2 & T3 should be durable.  But provides durability.  T4 & T5 should be aborted (effects not seen).  Steal buffer-pool frames crash! Desired No Force from uncommited Xacts? T1 T2  If not, poor throughput. T3  If so, how can we ensure T4 atomicity? T5 3 5 More on Steal and Force Basic Idea: Logging  Steal (why enforcing Atomicity is hard)  Record REDO and UNDO information, for every  To steal frame F: Current page in F (say P) is written to update, in a log. disk; some Xact holds lock on P.  Write sequentially to log (put it on a separate disk). • What if the Xact with the lock on P aborts?  Minimal info (“diff”) written to log, so multiple updates fit • Must remember the old value of P at steal time (to support in a single log page. UNDOing the write to page P).  Log: An ordered list of REDO/UNDO actions  No Force (why enforcing Durability is hard)  Log record for update contains:  What if system crashes before a page modified by a • <XactID, pageID, offset, length, old data, new data> committed Xact is written to disk?  and additional control info (which we’ll see soon).  Write as little as possible, in a convenient place, at commit time, to support REDOing modifications. 6 7

WAL & DB RAM Write-Ahead Logging (WAL) the Log LSNs pageLSNs flushedLSN  Each log record has a unique Log  The Write-Ahead Logging Protocol: Log records Sequence Number (LSN).  Must force the log record for an update before the flushed to disk  LSN is always increasing. corresponding data page gets to disk.  Each data page contains a • Needed for atomicity  Must write all log records for a Xact before commit. pageLSN.  The LSN of the most recent log record • Needed for durability for an update to that page.  System keeps track of flushedLSN.  Exactly how is logging (and recovery!) done? pageLSN “Log tail”  The max LSN flushed to disk so far. in RAM  We’ll study the ARIES algorithms.  WAL: Before a page is written,  pageLSN  flushedLSN 8 9 Log Record Fields Actions Logged  Page update  prevLSN: LSN of previous log record for the same  PageLSNset to LSN of log record transaction  Commit  Force-writes log record: appends record to log, flushes log up to this log record to  XactID: ID of transaction generating the log record stable storage  Xact is considered to have committed only after its commit log record is written to  type: Type of log record stable storage  Abort  Update log records also contain  End  Indicates that all additional steps required after writing a commit or abort log  pageID: ID of modified page record are completed (e.g., undo of Xact)  Undoing an update  length: number of bytes changed  Compensation log record (CLR), indicating that an action described by a log record  offset: offset where change occurred is undone (important if database crashes again during recovery!)  Written just before the action is undone  before-image: value of changed bytes before the change  Action described by CLR will never be undone, because decision to roll back Xact is final  after-image: value of changed bytes after the change 10 11 Other Log-Related State Normal Execution of an Xact  Transaction Table:  Series of reads and writes, followed by commit or  One entry per active Xact. abort.  Contains XactID, status (running, committed, aborted), and  We will assume that an individual write is atomic on disk. lastLSN. • In practice, additional details to deal with non-atomic writes.  Dirty Page Table:  Strict 2PL.  One entry per dirty page in buffer pool.  Contains recLSN — the LSN of the log record which first  STEAL, NO-FORCE buffer management, with Write- caused the page to be dirty. Ahead Logging. • Earliest log record that might have to be redone for this page during restart from crash 12 13

The Big Picture: What’s Stored Checkpointing Where  Periodically, the DBMS creates a checkpoint, in order to LOG minimize the time taken to recover in the event of a RAM DB system crash. Write to log:  begin_checkpoint record: Indicates when chkpt began. LogRecords Xact Table prevLSN  end_checkpoint record: Contains current Xact Table and Dirty Data pages lastLSN XactID Page Table. This is a `fuzzy checkpoint’: each status type • Other Xacts continue to run; so these tables are accurate only as of with a pageID the time of the begin_checkpointrecord. pageLSN Dirty Page Table length • No attempt to force dirty pages to disk recLSN offset • Effectiveness of checkpoint limited by oldest unwritten change to a master record before-image dirty page. (So it’s a good idea to periodically flush dirty pages to flushedLSN disk!) after-image  Store LSN of chkpt record in a known safe place (master record). 14 15 Abort Simple Transaction Abort (cont.)  For now, consider an explicit abort of a Xact.  No crash involved.  To perform UNDO, must have a lock on data.  We want to “play back” the log in reverse order,  No problem! UNDOing updates.  Before restoring old value of a page, write a CLR:  Get lastLSN of Xact from Xact table.  You continue logging while you UNDO!  Can follow chain of log records backward via the prevLSN  CLR has one extra field: undoNextLSN field. • Points to the next LSN to undo (= the prevLSN of the record we’re  Before starting UNDO, write an Abort log record. currently undoing).  CLRs never Undone (but they might be Redone when • For recovering from crash during UNDO! repeating history: guarantees Atomicity!)  At end of UNDO, write an “ end ” log record. 16 17 Transaction Commit Crash Recovery: Big Picture Oldest log  Write commit record to log.  Start from a checkpoint rec. of Xact active at crash  Found via master record.  All log records up to Xact’s lastLSN are flushed.  Guarantees that flushedLSN  lastLSN.  Three phases. Need to: Smallest  Note that log flushes are sequential, synchronous writes to recLSN in  Figure out which Xacts dirty page disk. committed and which failed table after since checkpoint (Analysis).  Many log records per log page. Analysis  REDO all actions of committed  Commit() returns. Xacts.  Write end record to log. Last chkpt  UNDO effects of failed Xacts. CRASH A R U 18 19