DBMS Topics
Shadow Paging
Last Updated : 21 May, 2026
Shadow paging is an alternative recovery technique to log-based recovery. Instead of using a transaction log to undo/redo operations, it maintains two page tables simulta
What is Shadow Paging?
Shadow paging is an alternative recovery technique to log-based recovery. Instead of using a transaction log to undo/redo operations, it maintains two page tables simultaneously:
- Current Page Table: Points to the most recent (in-progress) version of pages
- Shadow Page Table: Points to the stable (last committed) version of pages
On COMMIT, the shadow table is updated. On ABORT or CRASH, the shadow table is simply restored — no log needed.
How Shadow Paging Works
Setup
| A page table maps logical page numbers | physical disk addresses. |
| │ P1 | Block 10 │ |
| │ P2 | Block 20 │ |
| │ P3 | Block 30 │ |
| │ P1 | Block 10 (unchanged) │ |
| │ P2 | Block 45 (modified) │ ← new block for modified P2 |
| │ P3 | Block 30 (unchanged) │ |
Write Operation
COMMIT
On COMMIT
1. Flush all modified pages (in current page table) to disk
2. Make current page table the new shadow page table
(overwrite shadow table pointer with current table pointer)
3. Free old blocks that are no longer referenced
4. Done — no log replay needed!
After commit
SHADOW = CURRENT (both point to latest committed state)
ABORT / CRASH Recovery
Shadow Paging Diagram
BEFORE TRANSACTION
Shadow: P1→B10, P2→B20, P3→B30
Current: P1→B10, P2→B20, P3→B30 (identical at start)
DURING TRANSACTION (T modifies P2 and P3)
Shadow: P1→B10, P2→B20, P3→B30 ← untouched (old versions safe)
Current: P1→B10, P2→B45, P3→B67 ← new blocks created for modifications
ON COMMIT
Shadow: P1→B10, P2→B45, P3→B67 ← shadow updated atomically
Current: (same as shadow)
Old blocks B20, B30 freed.
ON ABORT / CRASH
Discard current page table.
Shadow: P1→B10, P2→B20, P3→B30 ← reverts to pre-transaction state
New blocks B45, B67 freed.
Advantages of Shadow Paging
- No transaction log needed — no log write overhead
- Simple, fast recovery — just discard current table on crash
- No undo/redo processing during recovery
- Atomicity guaranteed — page table switch is atomic
Disadvantages of Shadow Paging
- Fragmentation: Pages scattered across disk (no locality) → poor performance for sequential access
- Garbage collection: Old shadow pages need explicit freeing → overhead
- Commit overhead: Must flush ALL modified pages to disk at commit (not just log)
- Not suitable for concurrent transactions — complex when multiple transactions run simultaneously
- Difficult to extend to multi-page updates spanning transactions
Shadow Paging vs. Log-Based Recovery
| Feature | Shadow Paging | Log-Based Recovery |
|---|---|---|
| Recovery mechanism | Page table swap | Log replay |
| Recovery speed | Instant | Proportional to log |
| Normal operation cost | Page copying | Log writes |
| Concurrency support | Difficult | Well-supported |
| Disk fragmentation | High | Low |
| Used in practice | Rarely | Almost universally |
Practical Use
Shadow paging is rarely used in modern production DBMS due to its fragmentation and concurrency limitations. It is mainly used in:
- Small, single-user embedded databases
- Academic/research settings
- SQLite uses a form of shadow paging for its rollback journal
Most production DBMS (Oracle, MySQL, PostgreSQL, SQL Server) use log-based recovery (WAL).
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Shadow Paging.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this DBMS topic.
Search Terms
dbms, database management system, database notes, sql, unit, shadow, paging, shadow paging
Related DBMS Topics