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
Recommend
More recommend
