1. Enforcing the Atomic and Durable Properties
Recovery
Enforcing the Atomic and Durable Properties
Copyright © Curt Hill

2. Copyright © 2003-2008 - Curt Hill
What dangers?
System crashes
Power failure
Hardware failure
Disk failure
Partial writes during crash
Copyright © Curt Hill

3. Several Managers Interact
Recovery manager
Receives control when database restarts
Puts database into a consistent state
Transaction manager
Active during regular processing
Manages locks
Manages rollback and commit processing
Buffer manager
Copyright © Curt Hill

4. Buffer Manager Issues: Stealing
T1 has a page in frame S with changed data but is not yet committed
T2 needs a page
The replacement policy points at S
T2 steals the frame, which makes the buffer manager write the page to disk
We now have uncommitted data on disk, but better throughput
A no steal policy disallows this
Copyright © Curt Hill

5. Buffer Manager Issues: Forcing
A transaction commits
Any changes to any pages are now forced to disk
Even if other transactions are now waiting for an exclusive lock
This is called a force approach
Requires more I/O than is required
Copyright © Curt Hill

6. Recovery and Buffer Managers
A Recovery manager would prefer:
No steal policy
Rollbacks need no disk I/O
Force policy
No redo of committed transactions that were not written
These are the most common choices
Copyright © Curt Hill

7. Copyright © 2003-2008 - Curt Hill
The Log
A file of changes needing to be made and when they are actually made
All the information needed to redo them in the event of crash
Machine readable, not necessarily people readable
Stable storage
Disk or tape, that can survive a crash
Usually multiple copies
Write Ahead Log (WAL)
Must write log and be sure that the write is now stable before allowing the transaction to proceed
Copyright © Curt Hill

8. Copyright © 2003-2008 - Curt Hill
Log Processing
A normal transaction needs to update a tuple
It must announce the change to the log before it actually does the change
The log must be physically written, so that both the change and log entry are not lost in a buffer
Actions that need recording on the log:
Intend to change
Changed
Commit
Page written to disk
The transaction manager may use this to rollback as well
Copyright © Curt Hill

9. Copyright © 2003-2008 - Curt Hill
ARIES
Recovery process
Used with a no-steal, force policy
Phase 1: Analysis
Find all active transactions and dirty pages
Phase 2: Redo
Find starting point
Execute the actions that were not finished for committed or rollbacked transactions
Phase 3: Undo
Rollback all transactions that did neither a commit or rollback
If reasonable these transactions are rescheduled
Copyright © Curt Hill

10. Copyright © 2003-2008 - Curt Hill
Checkpoints
The difficulty of recovery is proportional to the number of active transactions and log size at the time of death
Typically a database takes a checkpoint to keep this manageable
Stop processing of any further transactions
Allow each active transaction to continue to completion
Force all changed pages to disk
Flush or segment the log
Restart processing new transactions
Copyright © Curt Hill

11. Copyright © 2003-2008 - Curt Hill
Recovery Impact
The creation and maintenance of the log provides significant overhead
There are several things a Database Administrator may do to tune
How is the log stored?
What is the delay between a commit and forcing the page?
How often are checkpoints taken?
Copyright © Curt Hill