《浙江大学数据库系统概念十七,对应原版教材第五版》由会员分享，可在线阅读，更多相关《浙江大学数据库系统概念十七,对应原版教材第五版（12页珍藏版）》请在金锄头文库上搜索。
1、【教育类精品资料】,Chapter 17: Recovery System,Failure Classification Transaction State A quick view of Log-Based Recovery,Failure Classification,Transaction failure : Logical errors: transaction cannot complete due to some internal error condition System errors: the database system must terminate an active
2、transaction due to an error condition (e.g., deadlock) System crash: a power failure or other hardware or software failure causes the system to crash. Fail-stop assumption: non-volatile storage contents are assumed to not be corrupted by system crash Database systems have numerous integrity checks t
3、o prevent corruption of disk data Disk failure: a head crash or similar disk failure destroys all or part of disk storage Destruction is assumed to be detectable: disk drives use checksums to detect failures,Recovery Algorithms,Recovery algorithms are techniques to ensure database consistency and tr
4、ansaction atomicity and durability despite failures Recovery algorithms have two parts Actions taken during normal transaction processing to ensure enough information exists to recover from failures Actions taken after a failure to recover the database contents to a state that ensures atomicity, con
5、sistency and durability,Transaction State,Single step,Transaction State (Cont.),Active, the initial state; the transaction stays in this state while it is executing Partially committed, after the final statement has been executed. Failed, after the discovery that normal execution can no longer proce
6、ed. Aborted, after the transaction has been rolled back and the database restored to its state prior to the start of the transaction. Two options after it has been aborted: restart the transaction only if no internal logical error kill the transaction Committed, after successful completion.,Implemen
7、tation of Atomicity and Durability,The recovery-management component of a database system implements the support for atomicity and durability. The shadow-database scheme: assume that only one transaction is active at a time. a pointer called db_pointer always points to the current consistent copy of
8、 the database. all updates are made on a shadow copy of the database, and db_pointer is made to point to the updated shadow copy only after the transaction reaches partial commit and all updated pages have been flushed to disk. in case transaction fails, old consistent copy pointed to by db_pointer
9、can be used, and the shadow copy can be deleted.,Implementation of Atomicity and Durability (Cont.),Assumes disks to not fail Useful for text editors, but extremely inefficient for large databases: executing a single transaction requires copying the entire database. Will see better schemes later.,Th
10、e shadow-database scheme:,Recovery and Atomicity,Modifying the database without ensuring that the transaction will commit may leave the database in an inconsistent state. Consider transaction Ti that transfers $50 from account A to account B; goal is either to perform all database modifications made
11、 by Ti or none at all. Several output operations may be required for Ti (to output A and B). A failure may occur after one of these modifications have been made but before all of them are made. To ensure atomicity despite failures we first output information describing the modifications to stable st
12、orage without modifying the database itself. Then make the modification to database at commit point, or remove all the modification if the transaction failed (rollback),Log-Based Recovery,A log is kept on stable storage. The log is a sequence of log records, and maintains a record of update activiti
13、es on the database. When transaction Ti starts, it registers itself by writing a log record Before Ti executes write(X), a log record is written, where V1 is the value of X before the write, and V2 is the value to be written to X. Log record notes that Ti has performed a write on data item Xj Xj had
14、 value V1 before the write, and will have value V2 after the write. When Ti finishes it last statement, the log record is written.,Immediate DB Modification Recovery Example,Below we show the log as it appears at three instances of time. Recovery actions in each case above are: (a) undo (T0): B is restored to 2000 and A to 1000. (b) undo (T1) and redo (T0): C is restored to 700, and then A and B are set to 950 and 2050 respectively. (c) redo (T0) and redo (T1): A and B are set to 950 and 2050 respectively. Then C is set to 600,End of Chapter,
