How ARIES Guarantees Reliable Transaction Recovery in Databases

For transactional databases, the most critical function is to guarantee ACID properties, with atomicity and durability relying on the recovery subsystem. When a transaction cannot continue or the system crashes, the recovery subsystem must roll back or restore the database to a consistent state.

Logging Schemes

The recovery subsystem’s core is the recovery algorithm, which prepares for recovery during transaction execution, typically using log‑recording. Although logging adds overhead, it is essential for rollback and crash recovery. An alternative, Shadow Paging, copies data before modification and replaces the original after updates, but it is costly and rarely used in DBMS.

Physical Logging & Logical Logging

Logging is divided into Physical Logging, which records the before‑and‑after values of data items (or page IDs, offsets, lengths), and Logical Logging, which records only the operation (e.g., DELETE, UPDATE) without the actual data values.

Physical Logging vs Logical Logging

Logical Logging generates smaller logs but is harder to implement under concurrency, so most DBMS prefer Physical Logging to ensure deterministic replay. Some systems, like VoltDB, use Logical Logging because they execute operations sequentially.

Recovery System Optimization

Group Commit

Group Commit batches the flushing of multiple transaction logs to disk, using a dedicated log buffer and a background thread or flushing when the buffer fills.

Early Lock Release

Early Lock Release frees locks after the transaction’s work is done, before the log is flushed, reducing lock‑waiting time and improving concurrency.

ARIES Algorithm

Most disk‑based DBMS use the ARIES (Algorithms for Recovery and Isolation Exploiting Semantics) algorithm, which adopts the Steal + No‑Force policy. Each log record has a Log Sequence Number (LSN). The log also records transaction end markers to indicate commit completion.

ARIES Three‑Phase Recovery

Analysis: After a crash, the system reads the log, identifies active transactions and pages modified before the crash.

Redo: Replays all log records (including CLRs) from the earliest dirty page LSN to reconstruct the state at crash time.

Undo: Rolls back incomplete transactions by following Prev‑LSN links and generating Compensation Log Records (CLRs) to avoid double undo.

Log Record Structure

ARIES logs contain Update, Commit, Abort, End, and Compensation Log Records (CLR). CLRs record undo actions to ensure idempotent rollback.

Checkpointing

ARIES uses fuzzy checkpoints, allowing transactions to continue while recording Begin_Checkpoint and End_Checkpoint entries. The Master Record stores the checkpoint LSN for fast recovery start.

Simple Transaction Recovery

When a transaction aborts without a system crash, the system uses the Xact Table to locate the latest LSN, then follows Prev‑LSN links to undo changes, recording CLRs and finally an Abort and End record.

Failure Recovery

During a crash, the three phases (Analysis, Redo, Undo) are executed as described. If another crash occurs during recovery, CLRs ensure that already undone actions are not redone, allowing the recovery process to continue safely.

Summary

ARIES is a mature recovery system that guarantees transaction atomicity and durability using WAL, Steal + No‑Force, and a three‑phase process (Analysis, Redo, Undo). It employs LSNs to link logs, Page LSNs for dirty pages, and fuzzy checkpoints to reduce recovery overhead.