Recovery and Atomicity (Cont.) To ensure atomicity despite failures,we first output information describing the modifications to stable storage without modifying the database itself. We study two approaches: log-based recovery,and shadow-paging We assume (initially)that transactions run serially,that is,one after the other. Database System Concepts,5th Edition,Oct 5,2006 17.12 ©Silberschat乜，Korth and Sudarshan
Database System Concepts, 5 17.12 ©Silberschatz, Korth and Sudarshan th Edition, Oct 5, 2006 Recovery and Atomicity (Cont.) To ensure atomicity despite failures, we first output information describing the modifications to stable storage without modifying the database itself. We study two approaches: log-based recovery, and shadow-paging We assume (initially) that transactions run serially, that is, one after the other
Log-Based Recovery A log is kept on stable storage. The log is a sequence of log records,and maintains a record of update activities on the database. When transaction T;starts,it registers itself by writing a <T;start>log record Before T;executes write(X),a log record <Ti,X,V1,V2>is written, where V,is the value of X before the write,and V2 is the value to be written to X. Log record notes that T;has performed a write on data item X;Xi had value V;before the write,and will have value V2 after the write. When 7;finishes it last statement,the log record <T;commit>is written. We assume for now that log records are written directly to stable storage (that is,they are not buffered) Two approaches using logs Deferred database modification Immediate database modification Database System Concepts,5th Edition,Oct 5,2006 17.13 ©Silberschat乜，Korth and Sudarshan
Database System Concepts, 5 17.13 ©Silberschatz, Korth and Sudarshan th Edition, Oct 5, 2006 Log-Based Recovery A log is kept on stable storage. The log is a sequence of log records, and maintains a record of update activities on the database. When transaction Ti starts, it registers itself by writing a <Ti start>log record Before Ti executes write(X), a log record <Ti , X, V1 , V2> 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 value V1 before the write, and will have value V2 after the write. When Ti finishes it last statement, the log record <Ti commit> is written. We assume for now that log records are written directly to stable storage (that is, they are not buffered) Two approaches using logs Deferred database modification Immediate database modification
Deferred Database Modification The deferred database modification scheme records all modifications to the log,but defers all the writes to after partial commit. Assume that transactions execute serially Transaction starts by writing <T;start>record to log. A write(X)operation results in a log record <Ti,X,V>being written, where Vis the new value for X Note:old value is not needed for this scheme The write is not performed on X at this time,but is deferred. When Ti partially commits,<Ti commit>is written to the log Finally,the log records are read and used to actually execute the previously deferred writes. Database System Concepts,5th Edition,Oct 5,2006 17.14 ©Silberschat乜，Korth and Sudarshan
Database System Concepts, 5 17.14 ©Silberschatz, Korth and Sudarshan th Edition, Oct 5, 2006 Deferred Database Modification The deferred database modification scheme records all modifications to the log, but defers all the writes to after partial commit. Assume that transactions execute serially Transaction starts by writing <Ti start> record to log. A write(X) operation results in a log record <Ti , X, V> being written, where V is the new value for X Note: old value is not needed for this scheme The write is not performed on X at this time, but is deferred. When Ti partially commits, <Ti commit> is written to the log Finally, the log records are read and used to actually execute the previously deferred writes
Deferred Database Modification (Cont.) During recovery after a crash,a transaction needs to be redone if and only if both <T;start>and<T commit>are there in the log. Redoing a transaction Ti(redoT)sets the value of all data items updated by the transaction to the new values. Crashes can occur while the transaction is executing the original updates,or while recovery action is being taken example transactions To and T(To executes before Ti): To:read (A) T:read(C) A:-A-50 C:-C-100 Write(A) write(C) read(B) B:-B+50 write(B) Database System Concepts,5th Edition,Oct 5,2006 17.15 ©Silberschat乜，Korth and Sudarshan
Database System Concepts, 5 17.15 ©Silberschatz, Korth and Sudarshan th Edition, Oct 5, 2006 Deferred Database Modification (Cont.) During recovery after a crash, a transaction needs to be redone if and only if both <Ti start> and<Ti commit> are there in the log. Redoing a transaction Ti ( redoTi ) sets the value of all data items updated by the transaction to the new values. Crashes can occur while the transaction is executing the original updates, or while recovery action is being taken example transactions T0 and T1 (T0 executes before T1 ): T0 : read (A) T1 : read (C) A: - A - 50 C:- C- 100 Write (A) write (C) read (B) B:- B + 50 write (B)
Deferred Database Modification (Cont.) Below we show the log as it appears at three instances of time. <To start> <To start> <To start> <T0,A,950> <T0,A,950> <T0,A,950> <T0,B,2050> <T0,B,2050> <T0,B,2050> <To commit> <To commit> <T start> <T start> <T1,C,600> <T1,C,600> <T commit> (a) (b) (c) If log on stable storage at time of crash is as in case: (a)No redo actions need to be taken (b)redo(To)must be performed since <To commit>is present (c)redo(To)must be performed followed by redo(T)since <To commit>and <T;commit>are present Database System Concepts,5th Edition,Oct 5,2006 17.16 ©Silberschat乜，Korth and Sudarshan
Database System Concepts, 5 17.16 ©Silberschatz, Korth and Sudarshan th Edition, Oct 5, 2006 Deferred Database Modification (Cont.) Below we show the log as it appears at three instances of time. If log on stable storage at time of crash is as in case: (a) No redo actions need to be taken (b) redo(T0 ) must be performed since <T0 commit> is present (c) redo(T0 ) must be performed followed by redo(T1 ) since <T0 commit> and <Ti commit> are present