Shadow Paging

Definition

Shadow paging is a database recovery method in which the system maintains two page tables: a shadow page table that represents the last committed stable state of the database, and a current page table that stores updates made during a transaction. All modifications are written to new pages rather than overwriting old ones, and the database is switched to the new page table only when the transaction commits successfully.

In simple terms, the old version remains safe until the new version is completely ready.

Main Content

1. Page Table Mechanism

The database is divided into fixed-size pages, and a page table maps logical pages to physical disk locations.
Two versions of the page mapping are maintained:
Shadow page table: points to the committed, unchanged database pages.
Current page table: points to newly written pages created during the transaction.
When a transaction updates a page, the original page is never overwritten directly. Instead, a new page is allocated and the current page table is updated to point to that new page.

Example:
If logical page 5 originally points to disk block 100, and the transaction modifies it, the new version may be stored in block 250. The current page table points to 250, while the shadow page table still points to 100.

This separation is the key idea behind shadow paging.

2. Copy-on-Write Strategy

Shadow paging uses a copy-on-write approach, meaning pages are copied only when they need to be changed.
Unmodified pages are shared between the shadow and current versions, which avoids unnecessary duplication.
Only the pages affected by the transaction are rewritten into new locations.

For example, if a transaction updates only 3 pages out of 1000, only those 3 pages need to be copied. The remaining 997 pages can still be referenced from the original stable database state.

This makes updates safe because the original data is preserved until commit time.

3. Commit and Rollback Behavior

During commit, the system replaces the shadow page table with the current page table, making the new version of the database official.
During rollback or a crash before commit, the system simply discards the current page table and continues using the shadow page table.
Since the old state was never overwritten, recovery is quick and straightforward.

For example:

If a transaction fails halfway, no complicated undo process is needed.
The database can return to the previous stable state by ignoring the temporary updates.

This is one of the biggest advantages of shadow paging in transaction recovery.

Working / Process

1. Start with the shadow page table

The database begins with a stable, committed page table called the shadow page table.
This table points to the current valid pages of the database.
The shadow table is treated as the protected backup version.

2. Make updates using new pages

When a transaction modifies a page, the system does not overwrite the old page.
Instead, it allocates a fresh page elsewhere on disk and writes the new data there.
The current page table is updated to point to these new pages, while the shadow page table remains unchanged.

3. Commit by switching tables

Once all updates are complete and verified, the system commits the transaction by changing the database pointer from the shadow page table to the current page table.
The new page table becomes the official committed version.
If a crash happens before this switch, the shadow page table still represents the valid database, so recovery is immediate.

Example flow:

Initial state:
Shadow table -> P1, P2, P3

Transaction updates P2:
Shadow table -> P1, P2, P3
Current table -> P1, P2', P3

After commit:
Committed table -> P1, P2', P3

In this process, only page P2 was changed, while the others remained untouched.

Advantages / Applications

Fast recovery

Recovery after a crash is very quick because the system can simply discard uncommitted changes and rely on the shadow page table.
There is usually no need to scan long logs or perform complex undo operations.

No in-place updates

Since original pages are not overwritten directly, the risk of corrupting committed data is reduced.
This makes the method reliable for preserving database consistency.

Simple rollback

If a transaction fails, rollback is easy because the database just reverts to the shadow table.
This simplicity makes shadow paging easy to understand and implement in small systems.

Useful in systems requiring strong atomicity

It is suitable where it is important that a transaction either completes entirely or not at all.
It can be applied in database engines, file systems, and storage systems that use page-based memory management.

Safe commit process

The database only becomes updated when the new page table is fully ready.
This ensures that partial updates do not appear as committed data.

Good for educational understanding of recovery

Shadow paging is widely studied because it clearly demonstrates the atomic commit idea in database systems.
It helps students understand the difference between stable state and working state in transactions.

Summary

Shadow paging is a database recovery method that keeps a stable shadow copy and writes updates to new pages.
It uses a page table mechanism to separate committed data from temporary transaction changes.
The method is simple to recover from crashes because uncommitted changes can be ignored.
Important terms to remember: shadow page table, current page table, copy-on-write, commit, rollback