---
title: "Recovery from log: deferred vs immediate"
subject: "Database Management System"
chapter: 8
key: "semester_6/database_management_system:log-recovery-deferred-immediate"
source: https://www.bctengineer.com/q/semester_6/database_management_system/log-recovery-deferred-immediate
site: BCT Engineering
---

# Recovery from log: deferred vs immediate

Database Management System · Chapter 8: Crash Recovery

- Asked in: year not given
- Video: [Lec-120: Deferred Database Modification in DBMS | Log Based Recovery | Imp for UGC NET and KVS](https://www.youtube.com/watch?v=0YhOYqPeq0g) — Gate Smashers
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_6/database_management_system/log-recovery-deferred-immediate
- Whole chapter: https://www.bctengineer.com/md/semester_6/database_management_system/chapter-8

## Question

Consider the following log at the time of a crash.
Deferred modification: <T0 start>, <T0, A, 950>, <T0, B, 2050>, <T0 commit>, <T1 start>, <T1, C, 600>
Immediate modification: <T0 start>, <T0, A, 1000, 950>, <T0, B, 2000, 2050>, <T0 commit>, <T1 start>, <T1, C, 700, 600>
State the recovery actions (redo/undo) required for each transaction under both schemes.

## Short answer

Under deferred modification, redo T0 (A=950, B=2050) and no action for T1. Under immediate modification, redo T0 (A=950, B=2050) and undo T1 (restore C to 700).

## Answer

After a crash the system scans the log. A transaction with both <T start> and <T commit> is redone; a transaction with <T start> but no <T commit> is incomplete.

#### Deferred modification
In deferred modification, writes to the database are postponed until the transaction commits. The log record <T, X, new> holds only the new value.

Log: <T0 start>, <T0, A, 950>, <T0, B, 2050>, <T0 commit>, <T1 start>, <T1, C, 600>

| Transaction | Log status | Action |
|---|---|---|
| T0 | start and commit | **redo(T0)**: set A = 950, B = 2050 |
| T1 | start, no commit | **nothing** (no undo needed) |

T1 had not committed, so none of its writes had reached the database; its log records are simply ignored and C keeps its old value. No undo is needed in deferred modification. Redo is idempotent, so repeating it is safe.

#### Immediate modification
In immediate modification, updates may reach the database before commit. The log record <T, X, old, new> holds both values.

Log: <T0 start>, <T0, A, 1000, 950>, <T0, B, 2000, 2050>, <T0 commit>, <T1 start>, <T1, C, 700, 600>

| Transaction | Log status | Action |
|---|---|---|
| T0 | start and commit | **redo(T0)**: set A = 950, B = 2050 (new values) |
| T1 | start, no commit | **undo(T1)**: set C = 700 (old value); write <T1 abort> |

Order of recovery: in the classic scheme the undo pass scans the log backward and restores the old values of incomplete transactions (C = 700), and then the redo pass scans forward and reapplies the committed ones (A = 950, B = 2050). The newer "repeating history" algorithm does the redo pass first and then the undo pass. Here T0 and T1 touch different items, so both orders give the same result.

#### Final state after recovery
- A = 950, B = 2050 (T0 committed)
- C = 700 (T1's change removed)

| Scheme | Redo | Undo |
|---|---|---|
| Deferred | T0 | none |
| Immediate | T0 | T1 |

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. Under deferred modification, what is done for T0 (start and commit in log)?
   A. Nothing
   B. redo(T0), setting A = 950 and B = 2050
   C. undo(T0)
   D. Restore A = 1000
   Answer: B. A committed transaction may not have written to the database yet, so its new values are reapplied. (Key point: Deferred modification, T0)

2. Why does T1 need no undo under deferred modification?
   A. It committed
   B. None of its writes reached the database before commit, so its log records are ignored
   C. Its values are already old
   D. Undo is impossible
   Answer: B. Deferred writes happen only at commit, so an uncommitted transaction left no changes. (Key point: Deferred modification, T1)

3. What action is taken for T1 under immediate modification?
   A. redo(T1) setting C = 600
   B. undo(T1) restoring C = 700
   C. Nothing
   D. undo(T0)
   Answer: B. T1 has no commit record but may have written C = 600 to disk, so the old value 700 is restored. (Key point: Immediate modification, T1)

4. What is the final state after recovery in the immediate scheme?
   A. A = 1000, B = 2000, C = 600
   B. A = 950, B = 2050, C = 700
   C. A = 950, B = 2050, C = 600
   D. A = 1000, B = 2000, C = 700
   Answer: B. T0 is redone (A = 950, B = 2050) and T1 is undone (C = 700). (Key point: Recovery order)

## Related in Database Management System

- [RA: delete loans under 1000](https://www.bctengineer.com/question.md?key=semester_6%2Fdatabase_management_system%3Ara-delete-small-loans) — Database Management System, chapter 3

## Related in other subjects

- [Transaction recovery techniques](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atransaction-recovery) — Distributed System, chapter 8
- [Rock layer attitude: A 700 m N, C 600 m W](https://www.bctengineer.com/question.md?key=semester_4%2Fengineering_geology_ii%3Abh-rock-layer-a700n-c600w) — Engineering Geology II, chapter 6, asked 2×
- [SC filter: 6 dB between 1000 and 2000 rad/s](https://www.bctengineer.com/question.md?key=semester_5%2Ffilter_design%3Asc-filter-6db-500-4000) — Filter Design, chapter 9
- [TCTO numerical: optimal crashed time, Rs 3000/week](https://www.bctengineer.com/question.md?key=semester_8%2Fconstruction_management%3Atcto-2073-magh) — Construction Management, chapter 2, asked 2×
