What is ARIES?

Prerequisites(2)

Write-Ahead Log (WAL)Buffer Pool Manager

Builds on to(1)

ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) is the gold-standard crash recovery protocol used by most modern relational databases, including IBM DB2, SQL Server, and PostgreSQL (which uses a simplified variant). Its job is to restore the database to a consistent state after a crash, ensuring durability (committed transactions survive) and atomicity (uncommitted transactions are rolled back).

The Write-Ahead Log (WAL)

Every modification to a database page is first recorded in the Write-Ahead Log before the dirty page is flushed to disk. Each log record contains: the transaction ID, the page ID, the redo information (how to re-apply the change), and the undo information (how to reverse it). The WAL is written sequentially, making it very fast. Each record gets a monotonically increasing Log Sequence Number (LSN).

Checkpoints

Periodically, the database writes a checkpoint record to the WAL. The checkpoint captures a snapshot of two critical tables: the Dirty Page Table (DPT), listing all pages in the buffer pool that have been modified but not yet flushed, and the Active Transaction Table (ATT), listing all transactions that are currently running. Checkpoints limit how far back recovery must scan.

Three Phases of ARIES Recovery

Analysis Phase: Scan the WAL forward from the most recent checkpoint. Rebuild the Dirty Page Table and Active Transaction Table by processing each log record. At the end, you know which pages might be out of date on disk and which transactions were active at crash time.
Redo Phase: Starting from the earliest LSN in the Dirty Page Table (the oldest un-flushed change), replay every logged change forward. This restores the database to the exact state it was in just before the crash — including changes from uncommitted transactions. ARIES uses the "repeating history" principle: redo everything, no exceptions.
Undo Phase: Now roll back all transactions that were active (uncommitted) at crash time. Process their log records in reverse order, applying the undo information to reverse each change. This ensures atomicity.

Compensation Log Records (CLR)

When the undo phase reverses a change, it writes a CLR (Compensation Log Record) to the WAL. The CLR records that the undo has been performed, and contains a pointer to the next log record to undo. If the system crashes again during recovery, the CLRs prevent the same undo from being performed twice — the redo phase will replay the CLR, and the undo phase will skip past it.

Physiological Logging

ARIES uses physiological logging: records are physical at the page level (they identify a specific page) but logical within the page (they describe the operation, like "insert key X at position Y", rather than byte offsets). This allows pages to be reorganized internally without invalidating existing log records.

**ARIES** (Algorithm for Recovery and Isolation Exploiting Semantics) is the gold-standard crash recovery protocol used by most modern relational databases, including IBM DB2, SQL Server, and PostgreSQL (which uses a simplified variant). Its job is to restore the database to a consistent state after a crash, ensuring **durability** (committed transactions survive) and **atomicity** (uncommitted transactions are rolled back).

### The Write-Ahead Log (WAL)

Every modification to a database page is first recorded in the **Write-Ahead Log** before the dirty page is flushed to disk. Each log record contains: the transaction ID, the page ID, the **redo information** (how to re-apply the change), and the **undo information** (how to reverse it). The WAL is written sequentially, making it very fast. Each record gets a monotonically increasing **Log Sequence Number (LSN)**.

### Checkpoints

Periodically, the database writes a **checkpoint** record to the WAL. The checkpoint captures a snapshot of two critical tables: the **Dirty Page Table (DPT)**, listing all pages in the buffer pool that have been modified but not yet flushed, and the **Active Transaction Table (ATT)**, listing all transactions that are currently running. Checkpoints limit how far back recovery must scan.

### Three Phases of ARIES Recovery

1. **Analysis Phase**: Scan the WAL forward from the most recent checkpoint. Rebuild the Dirty Page Table and Active Transaction Table by processing each log record. At the end, you know which pages might be out of date on disk and which transactions were active at crash time.

2. **Redo Phase**: Starting from the earliest LSN in the Dirty Page Table (the oldest un-flushed change), replay **every** logged change forward. This restores the database to the exact state it was in just before the crash — including changes from uncommitted transactions. ARIES uses the "repeating history" principle: redo everything, no exceptions.

3. **Undo Phase**: Now roll back all transactions that were active (uncommitted) at crash time. Process their log records in **reverse** order, applying the undo information to reverse each change. This ensures atomicity.

### Compensation Log Records (CLR)

When the undo phase reverses a change, it writes a **CLR** (Compensation Log Record) to the WAL. The CLR records that the undo has been performed, and contains a pointer to the **next** log record to undo. If the system crashes *again* during recovery, the CLRs prevent the same undo from being performed twice — the redo phase will replay the CLR, and the undo phase will skip past it.

### Physiological Logging

ARIES uses **physiological logging**: records are **physical** at the page level (they identify a specific page) but **logical** within the page (they describe the operation, like "insert key X at position Y", rather than byte offsets). This allows pages to be reorganized internally without invalidating existing log records.

Real-Life: Database Crash During a Transfer

Real-World Example

Imagine a banking system executing two transactions when the server loses power:

T1 (committed): transferred $500 from Account A to Account B. Both the debit and credit were logged, and the COMMIT record was written to the WAL.
T2 (uncommitted): was halfway through transferring $200 from Account C to Account D. The debit from C was logged, but the transaction had not committed.

Recovery with ARIES:

Analysis: scans from the last checkpoint, discovers T1 is committed, T2 is active (no commit record found).
Redo: replays ALL changes — both T1's debit/credit AND T2's debit from C. The database now looks exactly as it did at crash time.
Undo: rolls back T2 by reversing the debit from C (adding $200 back). Writes a CLR for this reversal.

Result: T1's transfer is preserved (durability), T2's partial transfer is cleanly reversed (atomicity). The database is consistent.

Real systems using ARIES-style recovery:

PostgreSQL: uses WAL with a simplified ARIES-like protocol
MySQL InnoDB: implements full ARIES with redo and undo logs
SQL Server: uses a direct implementation of ARIES
IBM DB2: where ARIES was originally developed

ARIES: Three Recovery Phases

Step 1 of 3