Types of Recovery • Catastrophic – disk crash • Backup from tape; redo from log • Non-catastrophic: inconsistent state • Undo some operations • Redo other ops
Update Times • Deferred update • After transaction finish: write to log, then DB • No-undo/redo • Immediate update • Write to log and DB before transaction finished • Undo/redo • If all transactions are written to DB before commit: undo/no-redo
Recovery Concepts • Cache of DB disk pages in RAM • Dirty bit • In-place vs. shadowing • Before image (BFIM); after image (AFIM) • Log • Write-ahead logging (WAL) • Undo entries • Contains BFIM info • Redo entries • Contains AFIM info
Rollback • Roll back effect of aborted transaction • Replace current info. By BFIM info. From the log • May cascade to other transactions that have read modified items
All recovery operations must be idempotent: can be executed many times and have the effect of only being executed once • Implies that log values are absolute and never relative.
Deferred update • A transaction cannot change the database until it reaches its commit point. • A transaction does not reach its commit point until all its update operations are recorded in the log ad the log is force-written to disk. • No-UNDO/REDO
Immediate Update • database can be updated immediately without waiting for the transaction to commit, provided the log is written to disk first. • If all updates of a transaction are recorded in the database on disk before the transaction commits: UNDO/NO-REDO • If the transaction can commit before all its changes are written to the database: UNDO/REDO
Shadow Paging • At the beginning of a transaction the page table is copied and stored • Write updates write a new page to disk, never modifying pages • In recovery, free the modified pages, and restore the page table. • NO-UNDO/NO-REDO • Need checkpoints and logs for concurrency control • Disadvantages: • scatters data pages • shadow page table management overhead • garbage collection overhead
Two phase Commit • Need a global recovery manager • Phase 1: • each DB signals that it has finished its part of the transaction • coordinator sends “prepare to commit” message • DB’s force write logs to disk, return message “ready to commit”/”cannot commit” • Coordinator can time out and assum problem • Phase 2: • If all DB’s reply “OK”, coordinator sends commit. Recovery is possible • If some DB is “not OK”, coordinator sends “Roll back” • Failure in phase 1 requires roll back • Failure in phase 2 means a successful transaction can recover and commit.
Catastrophic Failure • Backup: • whole database & log • incremental snapshots of log • Cannot cover every conceivable situation • Uptime constraints: need to freeze database as they are being backed up
ARIES • Analysis • identifies dirty buffer pool pages, and active transactions at time of crash • Redo • repeats all actions in the log starting from last checkpoint • Undo • Undoes the actions of transactions that did not commit
ARIES principles • WAL • Repeating History during Redo • Logging changes during Undo
For more Information on ARIES see Chpt. 18 in Ramakrishnan’s DBMS book.