Recovery and Atomicity To ensure atomicity despite failures,we first output information describing the modifications to stable storage without modifying the database itself. We study log-based recovery mechanisms in detail We first present key concepts And then present the actual recovery algorithm Less used alternative:shadow-copy and shadow-paging (brief details in b00k) db-pointer db-pointer old copy of old copy of new copy of database database database shadow-copy (to be deleted) (a)Before update (b)After update Database System Concepts-7th Edition 19.11 @Silberschatz,Korth and Sudarshan
Database System Concepts - 7 19.11 ©Silberschatz, Korth and Sudarshan th Edition Recovery and Atomicity ▪ To ensure atomicity despite failures, we first output information describing the modifications to stable storage without modifying the database itself. ▪ We study log-based recovery mechanisms in detail • We first present key concepts • And then present the actual recovery algorithm ▪ Less used alternative: shadow-copy and shadow-paging (brief details in book) shadow-copy
Log-Based Recovery A log is a sequence of log records.The records keep information about update activities on the database. The log is kept on stable storage ■ When transaction T;starts,it registers itself by writing a <7;start>log record Before T;executes write(X),a log record <Ti X,Vi,V2> is written,where V,is the value of X before the write (the old value),and V2 is the value to be written to X(the new value). When T;finishes it last statement,the log record <Ti commit>is written. Two approaches using logs Immediate database modification Deferred database modification. Database System Concepts-7th Edition 19.12 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 19.12 ©Silberschatz, Korth and Sudarshan th Edition Log-Based Recovery ▪ A log is a sequence of log records. The records keep information about update activities on the database. • The log is kept on stable storage ▪ 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 (the old value), and V2 is the value to be written to X (the new value). ▪ When Ti finishes it last statement, the log record <Ti commit> is written. ▪ Two approaches using logs • Immediate database modification • Deferred database modification
Immediate Database Modification The immediate-modification scheme allows updates of an uncommitted transaction to be made to the buffer,or the disk itself. before the transaction commits Update log record must be written before database item is written We assume that the log record is output directly to stable storage 。 (Will see later that how to postpone log record output to some extent) 国 Output of updated blocks to disk can take place at any time before or after transaction commit ■ Order in which blocks are output can be different from the order in which they are written. The deferred-modification scheme performs updates to buffer/disk only at the time of transaction commit Simplifies some aspects of recovery But has overhead of storing local copy Database System Concepts-7th Edition 19.13 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 19.13 ©Silberschatz, Korth and Sudarshan th Edition Immediate Database Modification ▪ The immediate-modification scheme allows updates of an uncommitted transaction to be made to the buffer, or the disk itself, before the transaction commits ▪ Update log record must be written before database item is written • We assume that the log record is output directly to stable storage • (Will see later that how to postpone log record output to some extent) ▪ Output of updated blocks to disk can take place at any time before or after transaction commit ▪ Order in which blocks are output can be different from the order in which they are written. ▪ The deferred-modification scheme performs updates to buffer/disk only at the time of transaction commit • Simplifies some aspects of recovery • But has overhead of storing local copy
Transaction Commit A transaction is said to have committed when its commit log record is output to stable storage All previous log records of the transaction must have been output already Writes performed by a transaction may still be in the buffer when the transaction commits,and may be output later Database System Concepts-7th Edition 19.14 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 19.14 ©Silberschatz, Korth and Sudarshan th Edition Transaction Commit ▪ A transaction is said to have committed when its commit log record is output to stable storage • All previous log records of the transaction must have been output already ▪ Writes performed by a transaction may still be in the buffer when the transaction commits, and may be output later
Immediate Database Modification Example Log Write Output <To start> <T0A,1000,950> <T0,B,2000,2050> A=950 B=2050 <To commit> <T start> <T1,C,700,600> C=600 Ba,Bc Bc output before T1 <T commit> commits BA Note:By denotes block containing X. Ba output after To commits Database System Concepts-7th Edition 19.15 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 19.15 ©Silberschatz, Korth and Sudarshan th Edition Immediate Database Modification Example Log Write Output <T0 start> <T0 , A, 1000, 950> <T0 , B, 2000, 2050> A = 950 B = 2050 <T0 commit> <T1 start> <T1 , C, 700, 600> C = 600 BB , BC <T1 commit> BA ▪ Note: BX denotes block containing X. BC output before T1 commits BA output after T0 commits