Recovery Basics

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.