In this lesson, you will learn how a database engine uses its Write-Ahead Log (WAL) to reconstruct committed data after an unexpected power failure.
When power cuts out, the database is often left in a "dirty" state: some data reached the disk, but other changes were only sitting in memory (the buffer pool) and were lost instantly. To recover, the engine performs a process called ARIES (Algorithms for Recovery and Isolation Exploiting Semantics), which follows three specific phases upon reboot.
1. The Analysis Phase
The engine first scans the log forward from the last successful checkpoint. It identifies two groups of transactions: those that were successfully committed before the crash and those that were "in-flight" (active) when the power failed. It rebuilds the state of the system as it existed at the moment of the crash.
2. The Redo Phase
Next, the engine replays the log from the point of the last checkpoint to the end of the log. It repeats all operations—regardless of whether the transaction eventually committed or not. This brings the disk-based data files to the exact state they were in at the instant the power failed, including the "dirty" changes that were lost from memory.
3. The Undo Phase
Finally, the engine must ensure consistency. It scans the log backward, rolling back any transactions that were still active at the time of the crash. Since these transactions never finished, their partial changes must be undone to ensure the database remains in a consistent state.
For example, imagine a bank transfer log:
[Log Start]
1. Update Account A (-100)
2. Update Account B (+100)
3. COMMIT
4. Update Account C (-50)
[CRASH]
During the Redo phase, the engine will update A, B, and C on the disk. During the Undo phase, it sees that the transaction for Account C never reached a COMMIT record, so it reverses the -50 change to restore the original balance.
Key Takeaway: The database recovers by replaying all logs to recreate the pre-crash state, then undoing incomplete transactions to ensure ACID compliance.