Title and Author of Paper
ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. C. Mohan et al.
Summary
ARIES presents and validates the concept of write-ahead logging, providing industrial strength support for atomicity and durability. As described in the Red Book, write-ahead logging is a “near-ubiquitous technique for maintaining durability”. ARIES provides the reference implementation for “No Force, Steal” write-ahead logging used by most databases today. With a “No Force” policy, transactions can be committed without actually flushing dirty pages to disk, while a “Steal” policy implies dirty pages can be flushed to disk at any time. Combined, these two policies allow for high performance as the current state of pages in the database can be kept in memory, avoiding unnecessary I/O operations.
What are the motivations for this work?
For a database to be useful in industrial settings, it needs to provide strong guarantees that data cannot be lost. This implies that the database must be able to recover from error conditions. The paper describes an algorithm for recovery from three different failure types: transaction failures, DBMS crashes, and storage media failure.
What is the proposed solution?
The fundamental idea of database recovery is to log logical changes to the database to durable storage before applying those changes to the actual database. If this protocol is followed, then any failures can be recovered by using the change log itself. This simple idea is used throughout the paper to illustrate the recovery algorithms for transaction failure, crashes, and storage media failure.
As part of the ARIES protocol, each log is assigned a log sequence number (LSN) uniquely identifying the log record. Further, each page in the database records the LSN that modified the page. ARIES also tracks any in-flight transactions to be able to fully restore the database to the point-in-time of the crash before doing full recovery.
To perform recovery, ARIES uses the log and the transaction table during three passes: analysis, redo, and undo. During the analysis pass, the log is scanned to extract the dirty pages and in-flight transactions from the point of failure, determining the starting point where redo is required, and the in-flight transactions that must be rolled back. During the redo pass, the database is restored to the state it was at the time of failure. Finally, during undo pass, any in-flight transactions that failed have their changes rolled back. Combining these three passes restores the database to a consistent state.