Enforcing the Atomic and Durable Properties Recovery Enforcing the Atomic and Durable Properties Copyright © 2003-2008 - Curt Hill

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

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill

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 © 2003-2008 - Curt Hill