Below is a complete, MCA-level, exam-oriented explanation of Database Recovery Management Concepts and Methods — covering checkpoints, log-based recovery, ARIES, shadow paging, buffer management, and detailed examples.
This answer is perfect for 10–15 mark theory questions.
⭐ DATABASE RECOVERY MANAGEMENT – Concepts & Methods
Database Recovery Management ensures that a DBMS can restore the database to a correct (consistent) state after a failure such as:
- System crash
- Power failure
- Transaction failure
- Media failure (disk failure)
- Process failure
- Software bug
The goal is to guarantee ACID properties, especially Atomicity and Durability.
⭐ 1. Types of Failures in DBMS
✔ 1. Transaction Failures
- Logical errors (invalid input, data not found)
- Deadlocks causing automatic rollback
- Exceptions or logical aborts
✔ 2. System Failures
- Power outage
- Operating system crash
- Hardware faults
Memory lost ❌
Disk data safe ✔
✔ 3. Media Failures
- Disk crash
- Head-crash
- Bad sectors
Both memory + disk data may be lost.
✔ 4. Application Failures
- Bugs in programs
- Software issues
⭐ 2. Recovery Concepts
A. Stable Storage
A stable storage system maintains data even after failures.
Used for logging.
B. Log Records
Every change is recorded in a log file.
A log entry typically contains:
<TID, item, old_value, new_value>
Other entries:
<TID, start>
<TID, commit>
<TID, abort>
<checkpoint>
⭐ 3. Write-Ahead Logging (WAL) — CRITICAL
WAL Rule:
Log must be written to stable storage BEFORE actual data is written to disk.
Guarantees:
- Undo information is always available
- Redo information is always available
This is the foundation for recovery techniques.
⭐ 4. Recovery Techniques (Important)
There are three major classes:
- Log-Based Recovery (Undo/Redo/ARIES)
- Shadow Paging
- Checkpointing
Let’s discuss each in detail.
⭐ 5. LOG-BASED RECOVERY
There are three types:
- UNDO Logging
- REDO Logging
- UNDO + REDO (ARIES)
⭐ A. UNDO Logging (Backwards Recovery)
UNDO logging stores:
<T, X, old_value>
If a transaction aborts or the system crashes before commit, UNDO is used to restore old values.
Steps:
- For uncommitted transactions → UNDO all their changes
- Use old values from logs
Guarantees Atomicity.
⭐ B. REDO Logging (Forward Recovery)
REDO logging stores:
<T, X, new_value>
If system crashes after commit, redo ensures changes are reapplied.
Steps:
- For committed transactions → REDO all changes
Guarantees Durability.
⭐ C. UNDO + REDO Logging (Most used)
Both old and new values stored:
<T, X, old, new>
Used when:
- Some transactions committed
- Some were still running
- Crash occurs
- Must UNDO uncommitted
- Must REDO committed
This is the most practical technique used in DBMS.
⭐ 6. ARIES Recovery Algorithm (Advanced MCA Topic)
ARIES = Algorithm for Recovery and Isolation Exploiting Semantics
Developed by IBM, used in Oracle, SQL Server.
ARIES Principles:
- Write-Ahead Logging (WAL)
- Repeating History: REDO all actions including uncommitted (roll forward)
- Compensation Log Records (CLR) for UNDO
ARIES has 3 phases:
✔ Phase 1: Analysis
- Identify active transactions
- Determine checkpoint state
✔ Phase 2: REDO
- Reapply all operations (history)
- Starting from last checkpoint
✔ Phase 3: UNDO
- Rollback loser transactions
- Write CLRs
ARIES ensures high performance and correctness.
⭐ 7. Checkpointing
A checkpoint writes the current state of database + logs so that recovery starts from a safe point.
✔ Types of Checkpoints
1. Consistent Checkpoint
- All transactions paused
- Database written
- Expensive
2. Fuzzy Checkpoint (Most used)
- Transactions NOT paused
- Only dirty pages + log positions recorded
- Very fast
✔ Advantages:
- Reduces recovery time
- Avoids scanning logs from the beginning
⭐ 8. Shadow Paging
Shadow paging is an alternative to log-based recovery.
Two copies maintained:
Shadow Page Table (old, stable)
Current Page Table (updated)
On commit:
- New table becomes shadow
- Old table deleted
Advantages:
✔ No logs required
✔ Fast commits
Disadvantages:
✘ High copying cost
✘ Poor performance for large databases
✘ Does not support concurrency well
Hence rarely used in modern DBMS.
⭐ 9. Buffer Management in Recovery
- Dirty pages → written to disk
- Steal/no-steal policy
- Force/no-force policy
Recovery Policies:
| Policy | Meaning | Impact |
|---|---|---|
| Steal | Allows writing uncommitted data to disk | Needs UNDO |
| No-Steal | Uncommitted data stays in buffer | No UNDO |
| Force | Writes all pages at commit | No REDO |
| No-Force | Data not written at commit | Needs REDO |
Most DBMS use Steal + No-Force, requiring UNDO + REDO logs.
⭐ 10. Recovery from Different Failures
✔ A. Transaction Failure
- Use UNDO logs
- Abort transaction
✔ B. System Crash
- UNDO losers
- REDO winners
✔ C. Disk Failure
- Restore from periodic backup
- Apply redo logs
✔ D. Human/Logical Error
- Rollback
- Use time-based recovery (point-in-time)
⭐ 11. Example of Recovery
Logs:
<T1, start>
<T1, A, 100, 150>
<T2, start>
<T2, B, 200, 250>
<T1, commit>
<CRASH>
Recovery:
- T1 committed → REDO
- T2 not committed → UNDO
Outcome:
- A = 150
- B restored to 200
⭐ 12. Perfect 5–6 Mark Summary
Database Recovery ensures that the database remains consistent after failures.
It uses concepts like stable storage, write-ahead logging, undo/redo logs, and checkpoints.
Recovery methods include log-based recovery (undo, redo, undo/redo), ARIES algorithm, and shadow paging.
Checkpoints reduce recovery time by marking safe states.
Thus, recovery management guarantees the ACID properties, especially atomicity and durability.
