1. ARIES Overview xactionTable dirtyPgTable Checkpoint • 3 phases • Analysis • Reconstruct dirtyPg, xaction tables • Find redoLSN • Min(recLSN) in dirtyPgTable • Start from last checkpoint, scan forward • After analysis, conservative estimate of dirtyPgTable Disk

2. ARIES Overview xactionTable dirtyPgTable Checkpoint • Redo • Replay log from redoLSN • Replay all updates -- “Repeating History” • Idempotent thanks to pageLSN • Optimizations that allow us to avoid some writes • Physical logging : e.g., exact bytes, or byte-level diff Disk • 3 phases • Analysis

3. Analysis checkpoint Redo redoLSN Undo Min(SOTlosers) ARIES Overview xactionTable dirtyPgTable Checkpoint • Undo • Just undo “losers” • Xactions in the xaction table • Start at lastLSN, follow prevLSNs in the log • Logical UNDO -- e.g., “Remove record i, pg k” • Write CLRs as we go • Allow us to avoid multiple UNDOs Disk • 3 phases • Analysis • Redo

4. UNDO with CLR Losers: 3

5. UNDO with CLR

6. UNDO with CLR

7. UNDO with CLR

8. UNDO with CLR

9. UNDO with CLR

10. UNDO with CLR

11. UNDO with CLR

12. Why Physiological? • Why do we do physical REDO? (Hint: ARIES is !ATOMIC) • System not “action consistent” at crash • Why do we do logical UNDO? • More compact records • Physical layout may be different at UNDO time • E.g., suppose additional records in index since record was written • Why do we “repeat history”? • So that we can use physical REDO • If an action is redone, we have exactly the same layout on disk • pageLSN on disk lets us determine this