Most recovery systems use logs to record every change and then redo/undo after a crash. Shadow paging is an alternative recovery technique that avoids logs by using two sets of page tables: one for the current database state and one for the shadow (old) state.
In simple terms, shadow paging says:
“Instead of logging changes, keep a copy‑on‑write version; if a crash happens, the old copy is still valid.”
Basic Idea of Shadow Paging
In shadow paging:
The database is divided into fixed‑size pages, each stored on disk.
A page table maps logical page numbers to physical page locations on disk.
There are two page tables:
Current page table (used by active transactions).
Shadow page table (which remains unchanged until a transaction commits).
When a transaction modifies a page:
The DBMS creates a new copy of the page in a different physical location.
It updates the current page table to point to this new page.
The shadow page table still points to the old version of the page.
This is called copy‑on‑write: the physical page is only copied when it is modified.
How Recovery Works in Shadow Paging
If a crash happens:
The current page table may be incomplete or inconsistent.
The shadow page table is always consistent, because it was never updated during the transaction.
So, recovery is very simple:
The DBMS discards the current page table.
It discards all pages that were written by uncommitted transactions.
It restarts using the shadow page table, which points to the last consistent state.
Conceptually, this is like having two identical directories of files and editing in a separate copy; if the system crashes, you just go back to the original directory.
Committing a Transaction in Shadow Paging
When a transaction commits successfully:
The DBMS switches the shadow page table to point to the current page table (now made permanent).
The old shadow page table and its associated pages are marked as free and can be reused.
At this point, the new state is permanent, and the old state becomes the backup for the next cycle.
Advantages of Shadow Paging
No transaction log needed:
Recovery is done purely by switching page tables, so no WAL or redo/undo logic is required.
Simple recovery logic:
On crash, just use the old shadow page table; no scanning of logs.
Fast recovery:
Recovery time is independent of the number of transactions, because it is based on table switching, not log reading.
Disadvantages of Shadow Paging
Extra disk space:
Two copies of many pages and two page tables must be maintained.
Page‑level overhead:
Every modified page is copied, even if only a small part is changed.
No incremental writes:
The entire page is rewritten, not just a few bytes.
Less flexible for concurrency:
Harder to support high concurrency and fine‑grained updates compared to log‑based systems.
For beginners, shadow paging is like maintaining a draft version of a document while editing; if the power goes out, you always have the original version to fall back on.
Summary
Shadow paging in DBMS is a recovery technique that maintains two page tables (current and shadow) and copies pages on write instead of logging changes. On crash, the DBMS discards the current state and resumes from the consistent shadow state, enabling simple and fast recovery without a transaction log. While shadow paging is easy to implement and recover from, it uses more disk space and is less efficient for highly concurrent systems, so most modern databases prefer log‑based recovery with checkpointing.