1/29/2009 Outline Whats the problem ? ARIES Terminology A - PDF document

1/29/2009 Outline  What’s the problem ? ARIES  Terminology A Transaction Recovery Method  ARIES in action  Normal processing  System crash Simon Olberding Simon Olberding 1 1/29/2009 2 1/29/2009 ACID Discussion  Atomicity : Either all actions in the transaction occur, or  How much of the success of a database none occur management system depends on reliable and  Consistency : If each transaction is consistent and the DB efficient transaction management? starts in a consistent state, then the DB ends up being  Given that relational database management consistent. systems have been very successful, do you believe  Isolation : The execution of one Transaction is isolated from that of other transactions relational model has made the design of  Durability : The result of a committed transaction is stored transaction management algorithms easier and persistently. more efficient? Why or why not? Simon Olberding Simon Olberding 3 1/29/2009 4 1/29/2009 What is ARIES good for ? Goals Simplicity (Concurrency & recovery are complex)  Problem: How to ensure the Atomicity and Durability if a transaction 1. gets aborted or a media or device failure occurs? Operation Logging (higher concurrency level) 2.  Unroll transaction 3. Flexible storage management (avoid offline reorganization of data --> garbage collect)  redo transactions Partial rollbacks (faster than total rollback) 4.  ARIES supports methods to deal with the problem Flexible buffer management ( concurrency I/O) 5.  ARIES features: fine granularity locking Recovery independence (selective recovery+ image copy at different 6. 1. OO systems make users think in small objects granularities e.g. page oriented) 2. “Object -oriented system users may tend to have many terminal interactions during …” 7. Logical undo (concurrency) 3. More system use  more hotspots  need less tuning Parallelism and fast recovery (multiprocessors, normal processing 8. 4. Metadata is accessed often; cannot all be locked at once while recovery) Minimal overhead (min log data, min CPU usage) 9. Simon Olberding 1/29/2009 Simon Olberding 1/29/2009 5 6 1

1/29/2009 Excursus: Buffer management Handling the buffer pool  Policies  Force : make sure that every update is on disk before Page Requests from Higher Levels commit  Durability without REDO logging BUFFER POOL  Bad performance Transaction has to wait for the disk disk page  no Steal : don’t allow buffer -pool frames with uncommitted updates to overwrite committed data on disk. free frame DIRTY  Atomicity without UNDO logging MAIN MEMORY  Bad performance No Steal Steal No Steal Steal DISK Update DB No UNDO UNDO No Force Fastest No Force REDO REDO Q: When should a updated page be written to disc? Need for a policy No UNDO Force Slowest Force No REDO Simon Olberding Simon Olberding 7 1/29/2009 8 1/29/2009 I Write-Ahead Logging (WAL) Basic Idea: Logging  Record REDO and UNDO information, for every update, in  The Write-Ahead Logging Protocol: a log.  Must force log record for an update before the  Sequential writes to log (put it on a separate disk). corresponding data page gets to disk.  Minimal info (difference) written to log, so multiple updates fit in a  Must write all log records for a Xact before commit single log page.  #1 guarantees Atomicity.  Log: An ordered list of REDO/UNDO actions  With UNDO info (ARIES: logical undo, concurrency)  Log record contains:  #2 guarantees Durability. <XID, pageID, offset, length, old data, new data>  and additional control info (which we’ll see soon).  With REDO info (ARIES: physical REDO, simplicity, independency) Note: Now we can implement Steal/No-force Simon Olberding Simon Olberding 9 1/29/2009 10 1/29/2009 Log in WAL Outline  LSN: log sequence number for every log record  What’s the problem ?  Always increasing DISC  pageLSN :  Terminology  LSN of the most recent log record for an update to that page flushedLSN  ARIES in action  Part of the log is in RAM another part is already on disc  Normal processing RAM  System crash  Following the WAL-Protocol requires that flushedLSN >= pageLSN  Otherwise there would be an updated page which isn’t registered in the log on stable storage Simon Olberding 1/29/2009 Simon Olberding 1/29/2009 11 12 2

1/29/2009 Log Records The Big Picture: What’s Stored Where Possible log record types:  Update LogRecord fields: LOG RAM DB  Commit prevLSN LogRecords transID  Abort Xact Table LSN Data pages type lastLSN prevLSN  End (signifies end of commit or pageID each status XID abort) with a length type update pageLSN Dirty Page Table pageID  Compensation Log offset records recLSN length Records (CLRs) only before-image Master record offset after-image flushedLSN  for UNDO actions before-image UndoNxtLSN after-image CLR only Simon Olberding 13 Simon Olberding 1/29/2009 1/29/2009 before and after image are the data before and after the update. Dirty page & Transaction table Outline  What’s the problem ?  Terminology  ARIES in action  Normal processing  System crash Simon Olberding Simon Olberding 17 1/29/2009 18 1/29/2009 Normal processing Checkpoints  Motivation: reduce the amount of recovery work after a  Updating / forward processing System crash  Adding records the log file  Idea: make a fuzzy snapshot of the DPT and TAT  1 st log entry: begin_ckp  Checkpoints (  next Slide)  2 nd log entry end_ckp. Save DPT and TAT on stable storage  Write begin_ckp LSN to a save place (master record)  Total/partial rollback  Fuzzy, because there might be transaction between  If transaction is aborted. Rollback to the last savepoint or the begin_ckp and end_ckp whole transaction  no double UNDO  No attempt to force dirty pages to disk  effectiveness of checkpoint limited by oldest unwritten change to a dirty page Simon Olberding 1/29/2009 Simon Olberding 1/29/2009 19 20 3

1/29/2009 Outline Crash Recovery: Big Picture  What’s the problem ? Oldest log rec. of Xact active  Start from a checkpoint (found via at crash  Terminology master record).  Three phases. Need to do: Smallest recLSN in dirty  ARIES in action – Analysis - Figure out which Xacts page table after  Normal processing Analysis committed since checkpoint, which failed.  System crash – REDO all actions. (repeat history) Last chkpt – UNDO effects of failed Xacts. CRASH A R U Simon Olberding Simon Olberding 21 1/29/2009 22 1/29/2009 Analysis Phase Redo pass  Recreate Transaction & Dirtypage table using the checkpoint  Motivation: Repeat history to reconstruct state at crash  Follow the log data from the checkpoint until the last LSN  Reapply all updates, also updates of looser transactions (like normal processing)  Procedure  End record: Remove Xact from Xact table.  Start at the log with the smallest recLSN  All Other records: Add Xact to Xact table, set lastLSN=LSN,  Redo all actions of log record or CLR unless change Xact status on commit.  Affected Pages is not in the DPT or  also, for Update records: If page P not in Dirty Page Table, Add  Affected page is in DPT and (recLSN > LSN or P to DPT, set its recLSN=LSN.  pageLSN >= LSN) (requires I/O, therefore last check) crash!  Redo = apply action + set pageLSN = LSN Result : TAT says which T1 Commit Xacts were active at time of  At the end of REDO, and End record is inserted in the log for Abort crash. T2 each transaction with status C which is removed from Xact Commit T3 table. DPT says which dirty pages MIGHT NOT have made it to T4 disk T5 Simon Olberding Simon Olberding 23 1/29/2009 24 1/29/2009 UNDO Pass Example: Crash  Motivation: remove looser transactions LSN LOG ToUndo = { l | l a lastLSN of a “loser” Xact} 00 begin_checkpoint RAM Repeat: 05 end_checkpoint  Choose largest LSN among ToUndo 10 update: T1 writes P5 prevLSN Xact Table  If this LSN is a CLR and undoNextLSN==NULL 20 update T2 writes P3 lastLSN  Write an End record for this Xact status 30 T1 abort Dirty Page Table  If this LSN is a CLR and undoNextLSN != NULL 40 CLR: Undo T1 LSN 10 undoNxtLSN recLSN  Add undoNextLSN to ToUndo 45 T1 End flushedLSN  Else this LSN is an update 50 update: T3 writes P1 Undo the update, write a CLR, add prevLSN to ToUndo 60 update: T2 writes P5 ToUndo Until ToUndo is empty CRASH, RESTART Simon Olberding 1/29/2009 Simon Olberding 1/29/2009 25 26 4