1. Recovery Basics

2. Types of Recovery Catastrophic – disk crash –Backup from tape; redo from log Non-catastrophic: inconsistent state –Undo some operations –Redo other ops

3. 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

4. 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

5. 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

6. 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.

7. 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

8. 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

9. 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

10. 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.

11. 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

12. 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

13. ARIES principles WAL Repeating History during Redo Logging changes during Undo

14. For more Information on ARIES see Chpt. 18 in Ramakrishnan’s DBMS book.