Recoverability tells us whether transactions can commit safely when one transaction reads data written by another transaction. Database recovery is the process of restoring a correct database state after failures such as transaction errors, system crashes or storage problems. The DBMS uses tools such as logs, Write-Ahead Logging (WAL), checkpoints, UNDO and REDO to recover work. This chapter also explains recoverable, cascadeless and strict schedules, transaction failures, immediate and deferred update, log records and crash-recovery examples in very easy language.
What Is Recoverability in DBMS?
A schedule is recoverable when a transaction that reads data written by another transaction commits only after the writer transaction commits. This prevents a transaction from permanently committing based on data that may later be rolled back.
Suppose T2 reads X after T1 writes X. If T2 depends on T1's value, T2 should not commit before T1. Otherwise, T2 may commit using data that later disappears if T1 aborts.
W1(X)
R2(X)
Safe commit order:
C1 before C2Recoverability memory line
Read from T1? Then do not commit before T1 commits.Before this chapter, revise Transactions & ACID Properties in DBMS and Serializability in DBMS. Serializability and recoverability are different correctness properties, and both matter.
What Is Database Recovery?
Database recovery is the process of bringing the database back to a correct state after a failure. Recovery decides which changes must be undone, which committed changes must be redone, and how the DBMS can restart without losing valid work.
Recoverable, Cascadeless and Strict Schedules
Recoverable
If Tj reads a value written by Ti, then Tj commits only after Ti commits.
Cascadeless
Tj is allowed to read a value written by Ti only after Ti has committed.
Strict
If Ti writes X, no other transaction may read or write X until Ti commits or aborts.
Recoverable Schedule With Example
Consider:
W1(X)
R2(X)
C1
C2T2 reads X written by T1. T2 commits only after T1 commits. Therefore the schedule is recoverable.
Now compare:
W1(X)
R2(X)
C2
A1T2 commits before T1. Later T1 aborts. T2 has already committed using a value that should no longer exist.
What Is a Cascadeless Schedule?
A cascadeless schedule does not allow a transaction to read uncommitted data written by another transaction.
Safe example:
W1(X)
C1
R2(X)
C2T2 reads X only after T1 commits, so if T1 fails before commit, T2 never sees that temporary value.
This avoids cascading rollback, where one aborted transaction forces several dependent transactions to roll back.
What Is Cascading Rollback?
Suppose T1 writes X, T2 reads that uncommitted X, and T3 then reads a value produced by T2. If T1 later aborts, T2 may need to abort because its work depended on T1. Then T3 may also need to abort.
T1 writes X
T2 reads X from T1
T3 reads data from T2
T1 aborts
Result:
T2 may abort
T3 may abortWhy cascadeless schedules help
Do not read uncommitted data -> avoid cascading rollbackWhat Is a Strict Schedule?
A strict schedule does not allow another transaction to read or write a data item written by an uncommitted transaction.
If T1 writes X:
W1(X)then T2 must wait before doing either:
R2(X)
or
W2(X)until T1 commits or aborts.
Strict schedules make recovery simpler because uncommitted values cannot be read or overwritten by other transactions.
Recoverable vs Cascadeless vs Strict Schedule
| Property | Recoverable | Cascadeless | Strict |
|---|---|---|---|
| Can read uncommitted data? | Yes, but commit must wait | No | No |
| Can overwrite uncommitted write? | Possibly | Possibly | No |
| Avoids cascading rollback? | Not always | Yes | Yes |
| Recovery simplicity | Lower | Better | Best among these three |
| Strength | Basic | Stronger | Strongest |
Transaction and Database Failures
What Is a Log in DBMS?
A log is a sequential record of important transaction events and database changes used during recovery.
Possible log records
Why the log matters
If the system crashes, the recovery manager can inspect the log to identify transactions that committed and transactions that were incomplete.
The old value can help with UNDO. The new value can help with REDO, depending on the recovery method.
What Is Write-Ahead Logging (WAL)?
Write-Ahead Logging means the required log record must reach stable storage before the corresponding changed database page is written to persistent database storage.
For a transaction commit, the DBMS also needs the required commit-related log information safely recorded before reporting the commit as durable.
WAL memory line
Log first, data page laterWAL is one of the core ideas that allows the DBMS to recover correctly after a crash.
What Is UNDO and REDO in Database Recovery?
UNDO
Remove the effects of transactions that did not successfully commit.
Think: restore an old value.
REDO
Reapply changes of committed transactions whose updates may not yet be reflected in database pages after a crash.
Think: restore the committed new value.
Crash Recovery Simulator
Assume T1 updates X and T2 updates Y. Click a crash case to see the recovery action.
Case 1: T1 changed X but did not commit
Recovery action
What Is a Checkpoint in DBMS?
A checkpoint is a recovery marker that lets the DBMS avoid scanning the entire log from the beginning after every crash.
The exact checkpoint procedure varies by recovery system. Some checkpoints may record active transactions and coordinate dirty pages or log positions rather than forcing every changed page immediately.
Deferred Update Recovery
In a deferred-update approach, database pages are not updated with a transaction's changes until the transaction reaches the required commit stage.
Because uncommitted changes are not written to the database, crash recovery mainly needs to REDO committed changes that were recorded but not yet reflected in the database.
Typical idea:
Record changes in log
Commit transaction
Apply committed changes to database
Recovery:
REDO committed transactions if neededTextbooks often summarize this style as NO-UNDO / REDO, though actual systems can use more sophisticated designs.
Immediate Update Recovery
In an immediate-update approach, a transaction's changed database page may reach storage before the transaction commits.
Therefore recovery may need:
WAL is crucial here because the log information needed for recovery must be safe before the changed database page is written.
Steal and No-Steal, Force and No-Force
These terms explain whether uncommitted pages may be written and whether committed pages must be forced to disk at commit time.
| Policy | Meaning | Recovery effect |
|---|---|---|
| Steal | A page containing uncommitted changes may be written to disk. | UNDO may be needed. |
| No-Steal | Uncommitted changed pages are not written to disk. | Reduces need for UNDO of disk-resident data. |
| Force | All changed pages of a committed transaction are forced to disk at commit. | Reduces need for REDO. |
| No-Force | Some committed changed pages may remain only in memory after commit. | REDO may be needed after crash. |
Many high-performance recovery systems use combinations such as steal/no-force, which makes both UNDO and REDO important.
What Happens If the System Crashes?
How Recovery Supports ACID Properties
For the complete ACID foundation, revise Transactions & ACID Properties in DBMS.
Serializability and Recoverability Are Not the Same
Serializability
Asks whether the interleaved operations are equivalent to some serial execution.
Recoverability
Asks whether commit order is safe when transactions depend on values written by other transactions.
A schedule can satisfy one property and still fail another. Good transaction processing needs both concurrency correctness and safe recovery behavior.
Revise Conflict & View Serializability for precedence-graph and schedule-equivalence problems.
Solved Recovery Example From a Log
Suppose the log before a crash is:
<T1 START>
<T1, X, old=100, new=120>
<T1 COMMIT>
<T2 START>
<T2, Y, old=50, new=80>
SYSTEM CRASHT1
T1 has a COMMIT record. If its changed page is not safely reflected in the database, recovery may need to REDO T1.
T2
T2 has no COMMIT record. If T2's changed page reached the database before the crash, recovery may need to UNDO T2 and restore Y to 50.
What Is ARIES Recovery?
ARIES is a well-known recovery method used as a reference model in database systems. Its name expands to Algorithms for Recovery and Isolation Exploiting Semantics.
At a high level, ARIES-style recovery is commonly described using three phases:
This is an advanced topic. For semester-level basics, understanding logs, WAL, checkpoints, UNDO and REDO is usually the important foundation.
What Is Shadow Paging?
Shadow paging is a recovery technique that keeps an old stable page table while updates are directed to new pages. If the transaction commits, the system can switch to the new page table. If it fails, the old stable version can still be used.
Log-based recovery
Uses transaction logs, WAL, checkpoints and UNDO/REDO logic.
Shadow paging
Uses old and new page mappings rather than normal UNDO/REDO logging for the same role.
Shadow paging is useful conceptually, but modern general-purpose database systems often rely heavily on log-based recovery techniques.
Recoverability and Recovery Mistakes to Avoid
How to Write Recoverability and Recovery in Semester Exams
Definition
Define recoverable schedule or database recovery and write one short example.
Compare schedules
Explain recoverable, cascadeless and strict schedules, or explain log, WAL, checkpoint, UNDO and REDO.
Full recovery answer
Cover failures, schedule safety, logging, WAL, checkpoints, immediate/deferred update and a crash-recovery example.
For presentation, revise How to Write High-Scoring Answers in University Semester Exams. For revision priority, use the previous-year-paper method.
Practice Questions With Answers
1. What is a recoverable schedule?
A schedule is recoverable when a transaction that reads data from another transaction commits only after the writer transaction commits.
2. What is a cascadeless schedule?
A cascadeless schedule allows a transaction to read data written by another transaction only after the writer has committed.
3. What is a strict schedule?
A strict schedule prevents other transactions from reading or writing a data item written by an uncommitted transaction.
4. What is cascading rollback?
Cascading rollback happens when one aborted transaction forces other dependent transactions to abort because they used its uncommitted data.
5. What is a database log?
A database log records important transaction events and changes so the DBMS can recover after failures.
6. What is Write-Ahead Logging?
WAL requires the needed log record to reach stable storage before the related changed database page is written to persistent storage.
7. What is the difference between UNDO and REDO?
UNDO removes incomplete uncommitted effects, while REDO reapplies committed effects that may be missing after a crash.
8. What is a checkpoint?
A checkpoint is a recovery marker that helps the DBMS reduce the amount of log history it must examine after a crash.
9. What is the difference between immediate and deferred update?
Deferred update delays database writes until commit and mainly needs REDO, while immediate update may write before commit and can require both UNDO and REDO.
10. What should I study after database recovery?
Study locking protocols, Two-Phase Locking, deadlocks, timestamp ordering, MVCC and advanced concurrency control.
Recoverability and Recovery One-Minute Revision Sheet
Ultimate memory line
Safe commits = recoverability · Safe crash restart = recoveryFrequently Asked Questions
What is recoverability in DBMS in simple words?
Recoverability means a transaction should not commit permanently before the transaction whose data it used has safely committed.
What is database recovery in DBMS?
Database recovery is the process of restoring a correct database state after transaction failures, system crashes or storage problems.
What is the difference between recoverable, cascadeless and strict schedules?
Recoverable controls commit order, cascadeless prevents reading uncommitted data, and strict also prevents reading or overwriting data written by an uncommitted transaction.
What is a log in database recovery?
A log is a sequential record of transaction events and data changes used by the DBMS during crash recovery.
What is a checkpoint in DBMS recovery?
A checkpoint is a recovery marker that reduces how much of the log the DBMS needs to process after a crash.
What is the difference between UNDO and REDO?
UNDO removes uncommitted changes, while REDO reapplies committed changes that need to be restored after a failure.
What Should You Learn Next?
Next: Locking Protocols, 2PL & Deadlocks
You now understand how the DBMS handles safe commit dependencies and crash recovery. The next chapter should explain shared/exclusive locks, lock compatibility, Two-Phase Locking, strict 2PL, deadlocks, wait-for graphs and deadlock prevention.
For video revision after reading, use the DBMS YouTube study guide only as a secondary resource.
