1 / 22

Chapter 9 Recover System

Chapter 9 Recover System. 9.1 Failure Classification 9.2 Log-Based Recovery 9.2.1 Deferred Database Modification 9.2.2 Immediate Database Modification 9.2.3 Checkpoints 9.3 Recovery with Concurrent Transactions. 9.1 Failure Classification.

claudia-morton
Download Presentation

Chapter 9 Recover System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 9 Recover System • 9.1 Failure Classification • 9.2 Log-Based Recovery 9.2.1 Deferred Database Modification 9.2.2 Immediate Database Modification 9.2.3 Checkpoints • 9.3 Recovery with Concurrent Transactions

  2. 9.1 Failure Classification ① Transaction failure a. Logical error (internal condition) b. System error (system has entered an undesirable state) ②System crash a. hardware malfunction b. bug in the database software or the operating system ③Disk failure A disk block loses its content as a result of either a head crash or failure during a data transfer operation. volatile storage nonvolatile storagestable storage

  3. 9.2 Log-Based Recovery The log is a sequence of log records, recording all the update activities in the database. An update log record describes a single database write. It has these fields: ① Transaction identifier:is the unique identifier of the transaction that performed the write operation. ② Data-item identifier:is the unique identifier of the data item written. ③ Old value:is the value of the data item prior to the write. ④ New value:is the value that the data item will have after the write.

  4. 9.2 Log-Based Recovery We denote the various types of log records as: ① <Ti start>.Transaction Ti has started. ② <Ti,Xj,V1,V2>.Transaction Ti has performed a write on data item Xj, Xj had value V1 before the write, and will have value V2 after the write. ③ <Ti commit>.Transaction Ti has committed. ④ <Ti abort>.Transaction Ti has aborted. Notices: ① Whenever a transaction performs a write, it is essential that the log record for that write be created before the database is modified. ② The log must reside in stable storage.

  5. 9.2.1 Deferred Database Modification The deferred-modification technique ensures transaction atomicity by recording all database modifications in the log, butdeferring the execution of all write operations of a transaction until the transaction partially commits. The execution of transaction Ti proceeds as follows: ①Before Ti starts its execution, a record <Ti start> is written to the log. ②A write(X) operation by Ti results in the writing of a new record to the log. ③Finally, when Ti partially commits, a record<Ti commit> is written to the log.

  6. T1: read(C); C:=C-100; write(C); T0: read(A); A:=A-50; write(A); read(B); B:=B+50; write(B); 9.2.1 Deferred Database Modification T0: A transaction that transfers $50 from account A to account B. T1: A transaction that withdraws $100 from account C A:$1000 B: $ 2000 C:$700 <T0 start> <T0,A,950> <T0,B,2050> <T0 commit> <T1 start> <T1,C,600> <T1 commit>

  7. 9.2.1 Deferred Database Modification Log Database <T0 start> <T0,A,950> <T0,B,2050> <T0 commit> A=950 B=2050 <T1 start> <T1,C,600> <T1 commit> C=600 redo(Ti) sets the value of all data items updated by transaction Ti to the new values. deferring the execution of all write operations of a transaction until the transaction partially commits

  8. 9.2.1 Deferred Database Modification After a failure, the recovery subsystem consults the log to determine which transactions need to be redone. Transaction Ti needs to be redone if and only if the log contains both the record <Ti start> and the record <Ti commit>. Thus, if the system crashes after the transaction completes its execution, the recovery scheme uses the information in the log to restore the system to a previous consistent state after the transaction had completed.

  9. 9.2.1 Deferred Database Modification <T0 start> <T0 start><T0 start> <T0,A,950> <T0,A,950> <T0,A,950> <T0,B,2050> <T0,B,2050><T0,B,2050> <T0 commit><T0 commit> <T1 start> <T1 start> <T1,C,600> <T1,C,600> <T1 commit> a) b) c) Crash: write(B) No redo. Delete:log records of T0 A:$1000 B:$2000 Crash: write(C) Redo(T0). Delete:log records of T1 A:$950 B:$2050 C:$700 Crash: <T1 commit> Redo(T0).Redo(T1). A:$950 B:$2050 C:$600

  10. 9.2.2 Immediate Database Modification The immediate-modification technique allows database modifications to be output to the database while the transaction is still in the active state. Data modifications written by active transactions are called uncommitted modifications. In the event of a crash or a transaction failure, the system must use the old-value field of the log records to restore the modified data items to the values they had prior to the start of the transaction. Undo: before a transaction Ti starts its execution, the system writes the record <Ti start> to the log. During its execution, any write(X) operation by Ti is preceded by the writing of the appropriate new update record to the log. When Ti partially commits, the system writes the record <Ti commit>to the log.

  11. 9.2.2 Immediate Database Modification <T0 start> <T0,A,1000,950> <T0,B,2000,2050> <T0 commit> <T1 start> <T1,C,700,600> <T1 commit> Log Database <T0 start> <T0,A,1000,950> <T0,B,2000,2050> <T0 commit> A=950 B=2050 <T1 start> <T1,C,700,600> <T1 commit> C=600

  12. 9.2.2 Immediate Database Modification The recovery scheme uses two recover procedures: ①undo(Ti) restores the value of all data items updated by transaction Ti to the old values. ②redo(Ti) sets the value of all data items updated by transaction Ti to the new values. After a failure has occurred, the recovery scheme consults the log to determine which transactions need to be redone, and which need to be undone: ① Transaction Ti needs to be undone if the log contains the record <Ti start>, but does not contain the record <Ti commit>. ② Transaction Ti needs to be redone if the log contains both the record <Ti start> and the record <Ti commit>.

  13. 9.2.2 Immediate Database Modification <T0 start><T0 start><T0 start> <T0,A,1000,950> <T0,A,1000,950> <T0,A,1000,950> <T0,B,2000,2050> <T0,B,2000,2050><T0,B,2000,2050> <T0 commit><T0 commit> <T1 start> <T1 start> <T1,C,700,600> <T1,C,700,600> <T1 commit> Crash: write(B) Undo(T0) A:$1000 B:$2000 Crash: write(C) Undo(T1) Redo(T0).A:$950 B:$2050 C:$700 Crash: <T1 commit> Redo(T0).Redo(T1). A:$950 B:$2050 C:$600

  14. 9.2.3 Checkpoints When a system failure occurs,we need to search the entire log to determine those transactions that need to be redone and those that need to be undone. Difficulties: ① the search process is time consuming ② most of the transactions that, according to our algorithm, need to be redone have already written their update into the database. Although redoing them will cause no harm, it will nevertheless cause recovery to take longer.

  15. 9.2.3 Checkpoints Solution:checkpoint maintain the log&the system periodically performs checkpoints: ①output onto stable storage all log records currently residing in main memory. ② output to the disk all modified buffer blocks. ③ output onto stable storage a log record <checkpoint> Notice: Transactions are not allowed to perform any update actions, such as writing to a buffer block or writing a log record, while a checkpoint is in progress.

  16. Tt (system crash) Tb (checkpoint) Tc (checkpoint) Time T1 T2 T3 9.2.3 Checkpoints undo No need to perform a redo operation on T1 redo ①For all transactions Tk in T that have no <Tk commit> record in the log, execute undo(Tk). ② For all transactions Tk in T such that the record <Tk commit> appears in the log, execute redo(Tk).

  17. T1 T2 Read (C); $2000 C:=C*2; Write (C); $4000 Read (C); $4000 C:=C+2000; Write (C); $6000 ROLLBACK; C:=$2000 9.3 Recovery with Concurrent Transactions Problem: Lost update solution: If a transaction T has update a data item Q, no other transaction may update the same data item until T has committed or been rolled back. (strict two-phase locking)

  18. 9.3.1 Transaction Rollback We roll back a failed transaction, Ti, by using the log. The system scans the log backward; for every log record of the form <Ti,Xj,V1,V2> found in the log, the system restores the data item Xj to its old value V1, scanning of the log terminates when the log record <Ti, start> is found. Notice:Scanning the log backward is important <Ti,A,10,20> <Ti,A,20,30> <Ti,A,10,20> <Ti,A,20,30> 10 20 <Ti,A,10,20> <Ti,A,20,30> 10 20

  19. Tt (system crash) Tc (checkpoint) Time T1 T2 T3 T4 T5 9.3.2 Checkpoints <checkpoint L> redo undo No need to perform a redo operation on T1 redo undo

  20. 9.3.3 Restart Recovery • When the system recovers from a crash, it constructs two lists: Undo-list: consists of transactions to be undone Redo-list: consists of transactions to be redone • Construction steps: initially, they are both empty. The system scans the log backward, examining each record, until it finds the first <checkpoint> record: ① For each record found of the form <Ti commit>, it adds Ti to redo-list ② For each record found of the form <Ti start>, if Ti is not in redo-list, then it add Ti to undo-list. When the system has examined all the appropriate log records, it checks the list L in the checkpoint record. For each transaction Ti in L, if Ti is not in redo-list then it adds Ti to the undo-list.

  21. 9.3.3 Restart Recovery Recovery steps: ① the system rescans the log from the most recent record backward, and performs an undo for each log record that belongs transaction Ti on the undo-list . Log records of transactions on the redo-list are ignored in this phase. The scan stops when the <Ti start> records have been found for every transaction Ti in the undo-list. ② the system locates the most recent <checkpoint L> record on the log. Notice that this step may involve scanning the log forward, if the checkpoint record was passed in step 1. ③ the system scans the log forward from the most recent <checkpoint L> record, and performs redo for each log record that belongs to a transaction Ti that is on the redo-list. It ignores log records of transactions on the undo-list in this phase.

  22. Ti Tj Read (a); 10 A:=A*2; Write (A); 20 ROLLBACK; A:=10 Read (A); 10 A:=A+20; Write (A); 30 system crash 9.3.3 Restart Recovery Notice: It is important to undo the transaction in the undo-list before redoing transactions in the redo-list. Redo(Tj): A:=30 Undo(Ti): A:=10 Undo(Ti): A:=10 Redo(Tj): A:=30 <Ti,A,10,20> <Tj,A,10,30><Tj,commit>

More Related