Log-Based Recovery

In any Database Management System (DBMS), data integrity and consistency are very important. Databases often face unexpected issues such as system crashes, power failures, software errors, or hardware malfunctions. To handle such failures and ensure that no data is permanently lost or corrupted, recovery techniques are used.

One of the most widely used recovery methods is Log-Based Recovery. It ensures that even if a failure occurs, the database can be brought back to a consistent state using logs.

What is Log-Based Recovery?

Log-Based Recovery is a recovery technique in DBMS where all the transactions performed on the database are recorded in a special file known as a log file.
This log file maintains a history of actions so that in case of a failure, the database can use this information to redo (reapply) or undo (roll back) transactions and restore the database to a consistent state.

In simple terms:

• A log keeps track of all operations performed.
• If something goes wrong, the system looks into the log to decide whether to redo or undo the operations.

What is a Log File?

A log file is a sequential file maintained by the DBMS. Every time a transaction performs an operation, an entry is made into the log.

Each log entry usually contains:

1. Transaction ID (TID) – the identifier of the transaction.
2. Type of operation – e.g., WRITE, UPDATE, COMMIT, or ABORT.
3. Data item affected – the record or object being changed.
4. Old value – the value before the operation.
5. New value – the value after the operation.
6. Timestamps – the exact time of the operation.

This way, the log provides a complete history of all database changes.

How Does Log-Based Recovery Work?

The main idea is simple:

• Before-Image (Undo Logging): The log keeps the old value before any modification. If the transaction fails, the old value is restored.
• After-Image (Redo Logging): The log also stores the new value after modification. If a system crashes after committing a transaction, the new values are reapplied.

Thus, recovery can involve:

• UNDO – Roll back incomplete or failed transactions.
• REDO – Reapply committed transactions that were not fully written to disk.

Types of Log-Based Recovery

There are two main approaches:

1. Undo Logging

• The log stores the old value of the data item.
• Rule: The old value must be written to the log before the actual database update.
• In case of failure:
  • Transactions that did not commit are undone by restoring old values.
• Example: <T1, X, 50, 80> Here, transaction T1 updated X from 50 to 80. If T1 fails before commit, the system uses the log to restore X = 50.

2. Redo Logging

• The log stores the new value of the data item.
• Rule: The new value must be written to the log before updating the database.
• In case of failure:
  • Only committed transactions are redone by writing the new values again.
• Example: <T2, Y, 100, 150> If T2 had committed but the database crashed before updating Y, the system will redo and set Y = 150.

3. Undo/Redo Logging (Combined Approach)

• Most modern DBMS use this approach.
• The log maintains both old values (for UNDO) and new values (for REDO).
• Advantage: It handles both uncommitted and committed transactions in case of a crash.

Steps in Log-Based Recovery

1. Check the log file – Identify which transactions were active, committed, or aborted at the time of failure.
2. Undo uncommitted transactions – Roll back their effects using old values from the log.
3. Redo committed transactions – Ensure their effects are applied using new values from the log.
4. Bring the database to a consistent state – After undo and redo operations, the database is reliable again.

Example of Log-Based Recovery

Suppose the database has a value A = 200.
Two transactions occur:

• T1: Update A = 300 (committed).
• T2: Update A = 400 (not committed).

Log file entries:

<T1, A, 200, 300>
<T2, A, 300, 400>
<T1, COMMIT>

Now the system crashes.

• Since T1 was committed → Redo T1 → A = 300.
• Since T2 was not committed → Undo T2 → A remains 300.

Final consistent value: A = 300.

Advantages of Log-Based Recovery

1. Ensures atomicity and durability of transactions.
2. Helps recover from system crashes quickly.
3. Provides a reliable way to track all changes.
4. Supports both undo and redo operations.
5. Works well with concurrent transactions.

Disadvantages of Log-Based Recovery

1. Overhead of logging – Writing to the log for every action may slow down the system.
2. Storage requirements – Log files can become very large.
3. Complexity – Implementing undo/redo rules can be difficult.

Conclusion

Log-Based Recovery in DBMS is a powerful mechanism to ensure that even if failures occur, the database can be brought back to a consistent state. By keeping detailed logs of every transaction, DBMS can undo incomplete work and redo committed work, maintaining data reliability and integrity.

In practice, most modern databases implement Undo/Redo Logging to balance efficiency and safety. While it adds some overhead, the benefits of maintaining a fault-tolerant system make it an essential part of database management.