数据库课件lec12recovery幻灯片.ppt

7 Crash Recovery Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY courtesy of Joe Hellerstein for some slides Review: The ACID properties Atomicity: All actions in the Xact (transaction) happen, or none happen. Consistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent. Isolation: Execution of one Xact is isolated from that of other Xacts. Durability: If an Xact commits, its effects persist. The Recovery Manager guarantees Atomicity Durability. Motivation Atomicity: Transactions may abort (“Rollback”). Durability: What if DBMS stops running? (Causes?) crash! Desired state after system restarts: T1 T3 should be durable. T2, T4 T5 should be aborted (effects should not be seen). T1 T2 T3 T4 T5 Abort Commit Commit Assumptions Concurrency control is in effect. Strict 2PL, in particular. Updates are happening “in place”. i.e., data is overwritten on (deleted from) the disk. Atomic Writes: writing a page to disk is an atomic action. In practice, additional details are needed to deal with non-atomic writes. Buffer Management Policy Plays a Key Role Shall we allow “dirty pages” in the buffer pool caused by an Xact T to be written to disk before T commits? If so, a second Xact T can “steal” a frame from T. In contrast, No-Steal. When an Xact T commits, must we ensure that all the “dirty pages” of T are immediately forced to disk? If so, we say that a “force” approach is used. In contrast, No-Force. Variants of Buffer Management Policy Force No Force No Steal Steal No REDO No UNDO UNDO No REDO UNDO REDO No UNDO REDO Force No Force No Steal Steal Slowest Fastest Performance Implications Logging/Recovery Implications Preferred Policy: Steal/No-Force STEAL (why enforcing Atomicity is hard) To steal frame F: Current page in F (say P) is written to disk; some Xact holds lock on P. What if the Xact with the lock on P aborts? Must remember the old value of P at steal time (to support UNDOing the write to page P). NO FOR