In a DBMS, system crashes, power outages, or disk failures can leave the database in an incomplete or inconsistent state. Log‑based recovery is the main technique used to rebuild a correct, consistent database after such failures.
The simple idea is:
“Before writing a change to the database, write it to a log file first. If the system crashes, use the log to undo uncommitted work and redo committed work.”
What Is a Transaction Log?
A transaction log is a special file that records the history of all important operations performed by transactions. Each log entry typically contains:
Transaction ID (e.g., T1, T2).
Type of operation (update, insert, delete, commit, abort).
Data item affected (for example, table name and row).
Old value (before the change, needed for undo).
New value (after the change, needed for redo).
Sequence number (to keep operations in order).
The log is stored on stable storage (like a fast disk or SSD) so it survives even if main memory or the primary database is lost.
Write‑Ahead Logging (WAL)
The Write‑Ahead Logging (WAL) rule is the core principle behind log‑based recovery. It says:
Any change to the database should be logged before it is written to the actual data files.
In steps:
For an update, the DBMS first writes a log record describing the change.
After the log entry is safely stored on disk, the DBMS applies the change to the database.
This guarantees that if a crash happens just after a COMMIT, the log still knows about the change and can reapply it during recovery.
How Log‑Based Recovery Works After a Crash
When the DBMS restarts after a failure, it performs log‑based recovery in a few conceptual phases:
Open the log file
Locate the last valid log entry and the latest checkpoint (if any).
Scan the log
Identify:
Transactions that committed before the crash.
Transactions that started but did not commit (incomplete or failed).
Redo phase (for committed transactions)
Reapply all changes made by committed transactions that may not have been fully written to disk.
Use the new values stored in the log to update the database.
Undo phase (for uncommitted transactions)
Roll back all changes made by uncommitted transactions.
Use the old values in the log to revert the database to the state before these transactions modified it.
In more advanced systems, this process is split into:
Analysis phase: determine which transactions were active at the time of the crash.
Redo phase: reapply committed changes.
Undo phase: roll back uncommitted changes.
Why Log‑Based Recovery Matters
It is the standard recovery mechanism in most modern databases (for example, SQL Server, PostgreSQL, Oracle).
It supports high concurrency because many transactions can run while the log takes care of durability.
It directly supports ACID properties:
Atomicity: through undo of uncommitted transactions.
Durability: through redo of committed transactions.
For beginners, think of log‑based recovery as keeping a detailed diary of every change; after a crash, the DBMS reads the diary, undoes any half‑done work, and re‑does the completed work to make the database correct again.
Summary
Log‑based recovery in DBMS is a recovery technique that uses a transaction log and the write‑ahead logging (WAL) rule to ensure that the database can be restored to a consistent state after a failure. The DBMS records every important operation in the log before updating the database, and after a crash, it redoes committed changes and undoes uncommitted ones. This method is crucial for maintaining atomicity and durability and forms the foundation for other recovery techniques like checkpointing, shadow paging, backup, and restore.