Log Based Recovery in Databases
In database management systems, log-based recovery is a fundamental technique used to maintain the consistency of the database in case of failures. A log is a series of documents kept for each transaction in a stable location. After any unanticipated failures, these logs guarantee that the system can recover and return the database to a consistent condition.
Every time a transaction makes a change to the database, it is noted in the log. Importantly, these logs must be written before the actual changes are applied to the database to ensure reliable recovery.
Consider an example where a transaction modifies a student’s city from “Noida” to “Bangalore.” The log entries for this transaction would be as follows:
- When the transaction starts:
<Tn, Start> - When the city is updated:
<Tn, City, 'Noida', 'Bangalore'> - When the transaction commits:
<Tn, Commit>
This logging ensures that even if the system crashes, all operations can be traced and recovered.
Machine Learning Tutorial:–Click Here
Data Science Tutorial:-Click Here
Complete Advance AI topics:- CLICK HERE
Deep Learning Tutorial:- Click Here
Approaches to Database Modification
1. Deferred Database Modification
The database is updated only after the transaction has committed when using the deferred modification technique. Up until that point, every modification is noted in the log but isn’t applied to the database. This technique simplifies recovery, especially in a single-user environment.
Recovery Steps in Deferred Update
- Find the log’s most recent checkpoint. The database already contains the transactions that were committed before to this checkpoint.
- After the last checkpoint, rerun the transaction using the log’s changes for any transactions that have both [Start_transaction, T] and [Commit, T].
- Since their modifications were never implemented, transactions that include only a [Start_transaction, T] record and no [Commit, T] call for no action.
Example
Consider two transactions:
- T1: Transfers Rs. 200 from account A to B.
- T2: Withdraws Rs. 100 from account C.
Initial balances:
- A = 1000, B = 1500, C = 2000
Logs during execution:
| Log Entry | Database Action |
|---|---|
[Start_transaction, T1] | – |
[Write, T1, A, 800] | Not applied yet |
[Write, T1, B, 1700] | Not applied yet |
[Commit, T1] | Apply T1: A = 800, B = 1700 |
[Start_transaction, T2] | – |
[Write, T2, C, 1900] | Not applied yet |
[Commit, T2] | Apply T2: C = 1900 |
In case of a system crash:
- Transactions with commit records are redone.
- Transactions without commit records are ignored.
This ensures data consistency while avoiding partial updates.
2. Immediate Database Modification
The immediate modification approach updates the database as the transaction executes, rather than waiting for commit. This method uses write-ahead logging (WAL) to record changes before applying them, ensuring recovery is possible even if a crash occurs.
Recovery Techniques
- Undo/No Redo: Transactions that fail before committing are rolled back; no redo is needed since changes are only applied after commit.
- Undo/Redo: Changes may be applied before commit. Transactions that fail before committing are undone, and committed transactions are redone from the log.
Recovery Steps in Immediate Update
- Find the latest checkpoint in the log. Transactions committed before this checkpoint need no action.
- Transactions with both
[Start_transaction, T]and[Commit, T]are redone. - Transactions with
[Start_transaction, T]but no[Commit, T]are undone, applying old values in reverse order for multiple writes.
Example
Using the same transactions T1 and T2:
| Log Entry | Database Action |
|---|---|
[Start_transaction, T1] | Begin T1 |
[Write, T1, A, 1000, 800] | A updated to 800 immediately |
[Write, T1, B, 1500, 1700] | B updated to 1700 immediately |
[Commit, T1] | Transaction committed |
[Start_transaction, T2] | Begin T2 |
[Write, T2, C, 2000, 1900] | C updated to 1900 immediately |
[Commit, T2] | Transaction committed |
In case of a crash:
- Transactions without a commit are undone.
- Transactions with a commit are redone if necessary.
Multiuser Environment
In a multiuser setting, immediate updates require careful handling of deadlocks. Uncommitted transactions must be rolled back to maintain consistency, while committed transactions are redone if the system crashes.
Complete Python Course with Advance topics:-Click Here
SQL Tutorial :–Click Here
Download New Real Time Projects :–Click here
Key Rules for Log-Based Recovery
- If the log contains
<Ti, Start>and<Ti, Commit>, the transaction needs to be redone. - If the log contains
<Ti, Start>but no<Ti, Commit>or<Ti, Abort>, the transaction needs to be undone.
By following these principles, log-based recovery ensures reliable and consistent recovery, regardless of whether the database uses deferred or immediate modification techniques.
Log-based recovery remains a cornerstone of database reliability, offering systematic strategies to handle failures while safeguarding data integrity. Whether using deferred updates for simplicity or immediate updates for efficiency, the log is always the ultimate source of truth.
types of log-based recovery in dbms
log-based recovery example
recovery techniques in dbms
recovery with concurrent transaction in dbms
shadow paging in dbms
checkpoint recovery in dbms
recovery and atomicity in dbms
advantages of log based recovery in dbms
log-based recovery example
types of log-based recovery in dbms
log-based recovery in distributed system
log-based recovery in dbms ppt
difference between log-based recovery and shadow paging
log based recovery in dbms in hindi
log based recovery in dbms geeksforgeeks
checkpoint recovery in dbms
log based recovery example
log based recovery dbms
log based recovery dbms example
