1 / 31

Recovery from Crashes

Recovery from Crashes. ACID. A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction, may change the DB from a consistent state to another consistent state. Otherwise it is rejected (aborted).

stefan
Download Presentation

Recovery from Crashes

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. Recovery from Crashes

  2. ACID • A transaction is atomic --all or none property. If it executes partly, an invalid state is likely to result. • A transaction, may change the DB from a consistent state to another consistent state. Otherwise it is rejected (aborted). • Concurrent execution of transactions may lead to inconsistency – each transaction must appear to be executed in isolation • The effect of a committed transaction is durablei.e. the effect on DB of a transaction must never be lost, once the transaction has completed. • ACID: Properties of a transaction: Atomicity, Consistency, Isolation, and Durability

  3. Database elements • Note: In our discussion, the notion of “DB element” will not be made specific. • A data element could be a tuple, block, a whole relation, etc. • A block is the unit of a disk read or write. • It’s better to consider blocks to be the elements.

  4. Primitive DB Operations of Transactions • INPUT(X)≡ copy the disk block containing the database element Xto a memory buffer • READ(X,t)≡ assign the value of buffer X to local variable t • WRITE(X,t)≡ copy the value of local variable t to buffer X • OUTPUT(X)≡ copy the block containing X from its buffer (in main memory) to disk

  5. Example • Consider the database elements A and B such that the constraint A=B must hold. • Suppose transaction T doubles A and B A := A*2; B := B*2; • Execution of T involves: • reading A and B from disk, • performing arithmetic in main memory, and • writing the new values for A and B back to disk.

  6. Example (Cont’d) Action t Buff A Buff B A in HD B in HD Read(A,t) 8 8 8 8 t:=t*2 16 8 8 8 Write(A,t) 16 16 8 8 Read(B,t) 8 16 8 8 8 t:=t*2 16 16 8 8 8 Write(B,t) 16 16 16 8 8 Output(A) 16 16 16 16 8 Output(B) 16 16 16 16 16 Problem: what happens if there is a system failure just before OUTPUT(B)?

  7. Undo Logging • Create a log of all “important actions.” A log is a sequential file opened for appending only. Entries that can occur in a log are: <START T> -- transaction T started. <T,X,OldX> -- database element X was modified; it used to have the value OldX <COMMIT T> -- transaction T has completed <ABORT T> -- Transaction T couldn’t complete successfully. • Intention for undo logging: • If there is a crash before transaction finishes, the log will tell us how to restore old values for any DB element X changed on disk.

  8. Undo Logging (Cont’d) Two rules of Undo Logging: • U1: Log records for a DB element X must be on disk before any database modification to X appears on disk. • U2: If a transaction T commits, then the log record <COMMIT T> must be written to disk only after all the database elements changed by T are written to disk. • In order to force log records to disk, the Log Manager needs a FLUSH LOG command that tells the buffer manager to copy to disk any log blocks that haven’t previously been copied to disk or that have been changed since they were last copied.

  9. Example: Action t Buff A Buff B A in HD B in HD Log Read(A,t) 8 8 8 8 <Start T> t:=t*2 16 8 8 8 Write(A,t) 16 16 8 8 <T,A,8> Read(B,t) 8 16 8 8 8 t:=t*2 16 16 8 8 8 Write(B,t) 16 16 16 8 8 <T,B,8> Flush Log Output(A) 16 16 16 16 8 Output(B) 16 16 16 16 16 <Commit T> Flush Log

  10. Recovery With Undo Logging 1. Examine the log to identify all transactions T such that <START T> appears in the log, but neither <COMMIT T> nor <ABORT T> does. • Call such transactions incomplete. 2. Examine each log entry <T, X, v> a) If T isn’t an incomplete transaction, do nothing. b) If T is incomplete, restore the old value of X In what order? From most recent to earliest. 3. For each incomplete transaction T add <ABORT T> to the log, and flush the log. • What about the transactions that had already <ABORT T> in the log? • We do nothing about them. If T aborted, then the effect on the DB should have been restored anyway.

  11. Example Action t Buff A Buff B A in HD B in HD Log Read(A,t) 8 8 8 8 <Start T> t:=t*2 16 8 8 8 Write(A,t) 16 16 8 8 <T,A,8> Read(B,t) 8 16 8 8 8 t:=t*2 16 16 8 8 8 Write(B,t) 16 16 16 8 8 <T,B,8> Flush Log Output(A) 16 16 16 16 8 Output(B) 16 16 16 16 16 <Commit T> Flush Log • If there is crash before OUTPUT(B) then this would result in T being identified as incomplete. • We would find <T,A,8> in the log and write A = 8 to the DB. • We also would find <T,B,8> in the log and “restore” B to value 8, although B has already this value. • Problem: What would happen if there were another system error during recovery? • Not really a problem. Recovery steps are idempotent, i.e. repeating them many times has exactly the same effect as performing them once.

  12. Checkpointing • Problem: in principle, recovery requires looking at the entire log!! • Simple solution: occasional checkpoint operation during which we: • Stop accepting new transactions. • Wait until all current transactions commit or abort and have written a Commit or Abort log record • Flush the log to disk • Enter a <CKPT> record in the log and flush the log again • Resume accepting transactions • If recovery is necessary, we know that all transactions prior to a <CKPT> record have committed or aborted and  need not be undone

  13. Example of an Undo log with CKPT <START T1> <T1,A,5> <START T2> <T2,B,10>  decide to do a checkpoint <T2,C,15> <T1,D,20> <COMMIT T1> <COMMIT T2> <CKPT> we may now write the CKPT record <START T3> <T3,E,25> <T3,F,30> If a crash occurs at this point?

  14. Nonquiescent Checkpoint (NQ CKPT) • Problem: we may not want to stop transactions from entering the system. • Solution: 1. Write a record <START CKPT(T1,...,Tk)> to log and flush to disk, where Ti’s are all current “active” transactions. 2. Wait until all Ti’s commit or abort, but do not prohibit new transactions. 3. When all T1…Tk are “done”, write the record <END CKPT> to log and flush.

  15. Recovery with NQ CKPT First case: • If the crash follows <END CKPT>, • Then we can restrict recovery to transactions that started after the <START CKPT>. Second case: • If the crash occurs between <START CKPT> and <END CKPT>, we need to undo: 1. All transactions T on the list associated with <START CKPT> with no <COMMIT T>. 2. All transactions T with <START T> after the <START CKPT> but with no <COMMIT T>. i.e. 1+2undo any incomplete transaction that is on the CKPT list or started after <START CKPT>.

  16. Example of NQ Undo Log <START T1> <T1,A,5> <START T2> <T2,B,10> <START CKPT (T1,T2)> <T2,C,15> <START T3> <T1,D,20> <COMMIT T1> <T3,E,25> <COMMIT T2> <END CKPT> <T3,F,30> A crash occurs at this point What if we have a crash right after <T3,E,25>?

  17. Undo Drawback • We cannot commit a transaction without first writing all its changed data to disk. • Sometimes we can save disk I/O if we let changes to the DB reside only in main memory for a while; • …as long as we can fix things up in the event of a crash…

  18. Redo Logging • Idea: Commit (log record appears on disk) before writing data to disk. • Redo­log entries contain the new values: • <T,X,NewX>= “transaction T modified X and the new value is NewX” • Redo logging rule: • R1. Before modifying DB element X on disk, all log entries (including <COMMIT T>) must be written to log (in disk).

  19. Example: Action t Buff A Buff B A in HD B in HD Log Read(A,t) 8 8 8 8 <Start T> t:=t*2 16 8 8 8 Write(A,t) 16 16 8 8 <T,A,16> Read(B,t) 8 16 8 8 8 t:=t*2 16 16 8 8 8 Write(B,t) 16 16 16 8 8 <T,B,16> <Commit T> Flush Log Output(A) 16 16 16 16 8 Output(B) 16 16 16 16 16

  20. Recovery for Redo Logging • Identify committed transactions. • Examine the log forward, from earliest to latest. • Consider only the committed transactions, T. • For each <T, X, v> in the log do: WRITE(X,v); OUTPUT(X); Note 1: Uncommitted transactions will have no effect on the DB (unlike in undo logging) This is because none of the changes of an uncommitted T have reached the disk Note 2: “Redoing” starts from the head of the log; In effect, each data item X will have the value written by the last transaction in the log that changed X.

  21. Checkpointing for Redo Logging • The key action that we must take between the start and end of checkpoint is to write to disk all the “dirty buffers.” • Dirty buffers are those that have been changed by committed transactions but not written yet to disk. • Unlike in the undo case, we don’t need to wait for active transactions to finish (in order to write <END CKPT>). • However, we wait for copying dirty buffers of the committed transactions.

  22. Checkpointing for Redo (Cont’d) 1.Write a <START CKPT(T1,...,Tk )> record to the log, where Ti’s are all the active transactions. 2. Write to disk all the dirty buffers of transactions that had already committed when the START CKPT was written to log. 3. Write an <END CKPT> record to log.

  23. Checkpointing for Redo (Cont’d) <START T1> <T1,A,5> <START T2> <COMMIT T1> <T2,B,10> <START CKPT(T2)> <T2,C,15> <START T3> <T3,D,20> <END CKPT> <COMMIT T2> <COMMIT T3> The buffer containing value A might be dirty. If so, copy it to disk. Then write <END CKPT>.  During this period three other actions took place. 

  24. Recovery with Ckpt. Redo Two cases: • If the crash follows <END CKPT>, we can restrict ourselves to transactions that began after <START CKPT>and those in the START list. • This is because we know that, in this case, every value written by committed transactions, before START CKPT(…), is now in disk. 2. If the crash occurs between <START CKPT> and <END CKPT>, then go and find the previous <END CKPT> and do the same as in the first case. • This is because we are not sure that committed transactions before START CKPT(…)  have their changes in disk.

  25. Undo/Redo Logging Problem: Both previous methods have some drawbacks: • Undo requires data to be written to disk in order to commit a transaction • this increases the # of disk I/O’s • Redo requires keeping all modified blocks buffered until after transaction commits • this increases the average # of buffers needed by transactions

  26. Undo/Redo Logging Scheme • Log entries are now: • <T, X, o, n> which means that transaction T updated DB elementX from old value o to new value n • Undo/Redo Rules UR1: Log records for a DB element X must be on disk before any database modification to X appears on disk. • Note: No constraint here about whether DB elements are sent to disk before or after the commit point. • This scheme has the characteristics of both UNDO and REDO schemes in that it writes the update log records first.

  27. Example: Action t Buff A Buff B A in HD B in HD Log Read(A,t) 8 8 8 8 <Start T> t:=t*2 16 8 8 8 Write(A,t) 16 16 8 8 <T,A,8,16> Read(B,t) 8 16 8 8 8 t:=t*2 16 16 8 8 8 Write(B,t) 16 16 16 8 8 <T,B,8,16> Flush Log Output(A) 16 16 16 16 8 <Commit T> Output(B) 16 16 16 16 16 Flush Log

  28. Undo/Redo Recovery The undo/redo recovery scheme: • Undo all incomplete transactions in the order latest-first. • Redo all committed transactions in the order earliest-first.

  29. Undo/Redo Checkpointing 1. Write <START CKPT(T1,...,Tk )> record to log, where Ti’s are all active transactions. 2. Write to disk “all” the dirty buffers, NOT ONLY OF THE COMMITED TRANSACTIONS. 3. Write an<END CKPT>record to log.

  30. Undo/Redo Recovery 1.Find problematic transactions: • Analysis phase: Scan the log backward back to previous checkpoint (pair of START CKPT, END CKPT); include every transaction T that either • started after the checkpoint began or • is in the “active” list at START CKPT. 2.If a transaction has no COMMIT record in the log, undo it. • Must proceed from the end to the front 3. If the transaction has a COMMIT record, redo it. • Must proceed from the earliest (front) to end

  31. Example <START T1> <T1,A,4,5> <START T2> <COMMIT T1> <T2,B,9,10> <START CKPT(T2)> <T2,C,14,15> <START T3> <T3,D,19,20> <END CKPT> <T2,E,20,21> <COMMIT T2> <COMMIT T3>  A crash occurs at this point • Suppose the crash occurs just before <COMMIT T3>. • We identify T2 as committed but T3 as incomplete. • It is not necessary to set B to 10 since we know that this change reached disk before <END CKPT>. • However, we need to REDO E; set E=21. • Also, we need to UNDO T3; set D=19

More Related