Course Content
Database Management System (DBMS)
Deferred & Immediate Update

Crash recovery mechanisms ensure that a database remains consistent and reliable, even when unexpected failures occur. Two common strategies used in logging and recovery are Deferred Update and Immediate Update. These approaches define when the actual data is written to the database and how the recovery handles different transaction states.

 



1. Deferred Update

In the Deferred Update approach, changes made by a transaction are not applied to the database until the transaction successfully completes (i.e., until it commits). All the changes are first recorded in the log, and only after a commit do they get written to the database.

 

How it works:
  • Transaction begins → Log records are written (not database)
  • Upon COMMIT → All changes are applied to the database
  • If a crash occurs before commit, nothing is written to the database, so no rollback is needed

 

Characteristics:
  • Simple to recover: only committed transactions are redone
  • Rollback is easy because no partial changes exist in the database
  • Efficient for systems where transactions often abort before commit

 

Example:
T1 starts
T1 wants to update A from 50 to 70 → log: <T1, A, 50, 70>
T1 commits → database is updated with A = 70

Recovery Strategy:
  • Redo all operations of committed transactions using the log
  • Ignore uncommitted transactions (no undo needed)

2. Immediate Update

With the Immediate Update strategy, changes made by a transaction can be written to the database before the transaction commits. However, the write-ahead logging (WAL) rule must be followed: the change must be logged first, then the database can be updated.

 

How it works:
  • Transaction begins → Changes are logged → Changes can be applied immediately to the database
  • If the transaction commits, no further action needed
  • If it fails or the system crashes, undo operations are necessary for incomplete transactions

 

Characteristics:
  • Requires both undo and redo operations during recovery
  • Suitable for real-time systems that demand immediate visibility of data
  • More complex but more flexible in high-concurrency environments

Example:
T2 starts
T2 updates B from 30 to 60 → log: <T2, B, 30, 60>
Change written to database immediately
T2 crashes before committing → database needs to undo B = 60 to B = 30

Recovery Strategy:
  • Undo all actions of uncommitted transactions
  • Redo actions of committed transactions


Summary Table
Feature Deferred Update Immediate Update
When DB is updated After commit Before commit (anytime)
Log Required? Yes Yes
Undo needed? No Yes (for uncommitted)
Redo needed? Yes (for committed) Yes (for committed)
Recovery Complexity Simple More complex
0% Complete
WhatsApp Icon

Hi Instagram Fam!
Get a FREE Cheat Sheet on System Design.

Hi LinkedIn Fam!
Get a FREE Cheat Sheet on System Design

Loved Our YouTube Videos? Get a FREE Cheat Sheet on System Design.