ARIES and the Recovery Algorithm That Made Write-Ahead Logging Systematic
IBM's ARIES recovery method combined write-ahead logging, log sequence numbers, repeating history and compensation records into a restart algorithm that could support fine-grained locking and partial rollback.
A committed transaction is useless if a crash can erase it
Database systems buffer pages in memory because forcing every change directly to disk would be slow. That performance choice creates a recovery problem: after a crash, disk may be missing committed updates while also containing updates from transactions that never committed.
Recovery algorithms must therefore reconstruct a legal state from an imperfect mixture of memory loss, partial page writes and transaction history.
System R established an important recovery lineage before ARIES
The 1981 description of System R’s recovery manager used a transaction log, undo and redo operations, checkpoints and commit processing to recover from failures.[1]
That work helped establish logging as a central tool for transactional recovery, but later systems wanted more flexible buffer management, finer-grained locking and more robust restart behavior.
ARIES was published as a general write-ahead-logging recovery method in 1992
C. Mohan, Don Haderle, Bruce Lindsay, Hamid Pirahesh and Peter Schwarz presented ARIES—Algorithm for Recovery and Isolation Exploiting Semantics—as a method supporting fine-granularity locking, partial rollbacks and write-ahead logging.[2]
The paper also records that ARIES ideas had already been implemented to varying degrees in IBM and research systems, making it both a formal description and a consolidation of production experience.[2]
Write-ahead logging makes the log more durable than the page change
The core WAL rule is that the log record describing an update must reach stable storage before the corresponding modified data page can be written there. Commit also requires the transaction’s relevant log records to be durable.[4]
This order lets recovery trust the log even when cached database pages were only partly flushed before the crash.
ARIES labels history with log sequence numbers
ARIES assigns log sequence numbers, or LSNs, to log records and records the relevant LSN on database pages. During recovery, the system can compare the page’s state with the log to decide whether a particular action still needs to be redone.[3]
The LSN turns recovery from a vague replay operation into a precise comparison between durable history and page state.
Restart recovery proceeds through analysis, redo and undo
ARIES first analyzes the log to reconstruct information about transactions and dirty pages. It then redoes history from the earliest point that may be missing on disk. Finally, it undoes the effects of transactions that had not committed when the crash occurred.[3]
The striking part is the redo rule: recovery can repeat updates even for transactions that will later be rolled back.
Repeating history simplifies the reconstruction problem
Instead of trying to decide too early which page state ‘should’ exist, ARIES first rebuilds the state the system had reached at the instant of failure. Only after that reconstruction does it remove the work of loser transactions.[2]
Compensation log records make undo itself recoverable
Rollback has to survive its own failures
If the system crashes while rolling back a transaction, recovery must not endlessly undo the same action again. ARIES writes compensation log records for undo operations and links them so recovery can resume progress after another failure.[2]
This is an important systems principle: recovery actions are themselves state changes that may need to survive a crash.
ARIES supports performance-friendly buffer policies
Recovery design can enable runtime performance
The method is compatible with policies in which dirty pages can be written before a transaction commits and committed pages do not have to be forced immediately to disk. Those choices reduce I/O pressure but make recovery more demanding.[2]
ARIES earns that performance freedom by keeping enough ordered history to reconstruct what happened.
Why ARIES belongs in database history
ARIES did not invent the idea of logging, undo or redo. Its historical importance is architectural: it assembled WAL, page LSNs, repeating history and logged undo into a coherent method suitable for sophisticated transaction systems.[1][2]
The result became a canonical way of teaching crash recovery because it exposes the deeper bargain of database performance: memory and disk may diverge during normal operation, so the system must preserve a trustworthy history capable of repairing them afterward. VLDB later recognized the ARIES line with a ten-year award talk that emphasized the broad impact of repeating history, compensation logging and related recovery techniques.[5]
Works Cited
- 01
- 02C. Mohan et al. — ARIES: A Transaction Recovery Method (1992) research.ibm.com
- 03
- 04UC Berkeley Red Book — Write-Ahead Logging redbook.cs.berkeley.edu
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead