120 likes | 364 Views
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. ARIES Overview. xactionTable.
E N D
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
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
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
UNDO with CLR Losers: 3
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