1 / 47

Recovery

Recovery. Integrity or correctness of data. Would like data to be “accurate” or “correct” at all times EMP. Name. Age. White Green Gray. 52 3421 1. Integrity or consistency constraints. Predicates data must satisfy Examples: - x is key of relation R - x  y holds in R

december
Download Presentation

Recovery

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 Yan Huang - CSCI5330 Database Implementation –Recovery

  2. Integrity or correctness of data • Would like data to be “accurate” or“correct” at all times EMP Name Age White Green Gray 52 3421 1 Yan Huang - CSCI5330 Database Implementation –Recovery

  3. Integrity or consistency constraints • Predicates data must satisfy • Examples: - x is key of relation R - x  y holds in R - Domain(x) = {Red, Blue, Green} - a is valid index for attribute x of R - no employee should make more thantwice the average salary Yan Huang - CSCI5330 Database Implementation –Recovery

  4. Definition: • Consistent state: satisfies all constraints • Consistent DB: DB in consistent state Yan Huang - CSCI5330 Database Implementation –Recovery

  5. Observation: DB cannot be consistent always! Example: a1 + a2 +…. an = TOT (constraint) Deposit $100 in a2: a2 a2 + 100 TOT  TOT + 100 Yan Huang - CSCI5330 Database Implementation –Recovery

  6. Example: a1 + a2 +…. an = TOT (constraint) Deposit $100 in a2: a2 a2 + 100 TOT  TOT + 100 a2 TOT . . . . . . 50 150 150 . . . . . . 1000 1000 1100 Yan Huang - CSCI5330 Database Implementation –Recovery

  7. Transaction: collection of actions that preserve consistency Consistent DB Consistent DB’ T Yan Huang - CSCI5330 Database Implementation –Recovery

  8. How can we prevent/fix violations? • cc: due to data sharing only • recovery: due to failures only Yan Huang - CSCI5330 Database Implementation –Recovery

  9. Will not consider: • How to write correct transactions • How to write correct DBMS • Constraint checking & repair That is, solutions studied here do not need to know constraints Yan Huang - CSCI5330 Database Implementation –Recovery

  10. Storage hierarchy x x Memory Disk Yan Huang - CSCI5330 Database Implementation –Recovery

  11. Operations: • Input (x): block with x  memory • Output (x): block with x  disk Read (x,t): do input(x) if necessary t  value of x in block Write (x,t): do input(x) if necessary value of x in block  t Yan Huang - CSCI5330 Database Implementation –Recovery

  12. Key problem Unfinished transaction Example Constraint: A=B T1: A  A  2 B  B  2 Yan Huang - CSCI5330 Database Implementation –Recovery

  13. 16 16 T1: Read (A,t); t  t2 Write (A,t); Read (B,t); t  t2 Write (B,t); Output (A); Output (B); failure! A: 8 B: 8 A: 8 B: 8 16 memory disk Yan Huang - CSCI5330 Database Implementation –Recovery

  14. <T1, start> <T1, A, 8> 16 16 16 16 Undo logging T1: Read (A,t); t  t2 A=B Write (A,t); Read (B,t); t  t2 Write (B,t); Output (A); Output (B); A:8 B:8 A:8 B:8 <T1, B, 8> <T1, commit> disk memory log Yan Huang - CSCI5330 Database Implementation –Recovery

  15. 16 BAD STATE # 1 One “complication” • Log is first written in memory • Not written to disk on every action memory DB Log A: 8 B: 8 A: 8 16 B: 8 16 Log: <T1,start> <T1, A, 8> <T1, B, 8> Yan Huang - CSCI5330 Database Implementation –Recovery

  16. 16 BAD STATE # 2 One “complication” • Log is first written in memory • Not written to disk on every action memory DB Log A: 8 B: 8 A: 8 16 B: 8 16 Log: <T1,start> <T1, A, 8> <T1, B, 8> <T1, commit> ... <T1, B, 8> <T1, commit> Yan Huang - CSCI5330 Database Implementation –Recovery

  17. Undo logging rules (1) For every action generate undo logrecord (containing old value) (2) Before x is modified on disk, logrecords pertaining to x must beon disk (write ahead logging: WAL) (3) Before commit is flushed to log, allwrites oftransaction must bereflected on disk Yan Huang - CSCI5330 Database Implementation –Recovery

  18. Recovery rules: Undo logging (1) Let S = set of transactions with<Ti, start> in log, but no <Ti, commit> (or <Ti, abort>) record in log (2) For each <Ti, X, v> in log, in reverse order (latest  earliest) do: - if Ti  S then - write (X, v) - output (X) (3) For each Ti  S do - write <Ti, abort> to log Yan Huang - CSCI5330 Database Implementation –Recovery

  19. What if failure during recovery? No problem!  Undo idempotent Yan Huang - CSCI5330 Database Implementation –Recovery

  20. To discuss: • Redo logging • Undo/redo logging, why both? • Checkpoints Yan Huang - CSCI5330 Database Implementation –Recovery

  21. <T1, start> <T1, A, 16> <T1, B, 16> <T1, commit> output 16 16 16 Redo logging (deferred modification) T1: Read(A,t); t t2; write (A,t); Read(B,t); t t2; write (B,t); Output(A); Output(B) A: 8 B: 8 A: 8 B: 8 DB memory LOG Yan Huang - CSCI5330 Database Implementation –Recovery

  22. Redo logging rules (1) For every action, generate redo logrecord (containing new value) (2) Before anything is modified on disk (DB),all log records for transaction thatmodify things (including commit) mustbe on disk Yan Huang - CSCI5330 Database Implementation –Recovery

  23. Recovery rules: Redo logging (1) Let S = set of transactions with <Ti, commit> in log (2) For each <Ti, X, v> in log, in forward order (earliest  latest) do: - if Ti  S then Write(X, v) Output(X) Yan Huang - CSCI5330 Database Implementation –Recovery

  24. Recovery is very, very SLOW ! Redo log: First T1 wrote A,B Last Record Committed a year ago Record (1 year ago) --> STILL, Need to redo after crash!! ... ... ... Crash Yan Huang - CSCI5330 Database Implementation –Recovery

  25. Undo Recovery – Better? • The first record without commit or abort should not be too far away from crash • But immediate update itself is expensive ... ... ... first record without commit or abort Yan Huang - CSCI5330 Database Implementation –Recovery

  26. Solution: Checkpoint (simple version) Periodically: (1) Do not accept new transactions (2) Wait until all transactions finish (3) Flush all log records to disk (log) (4) Flush all buffers to disk (DB) (do not discard buffers) (5) Write “checkpoint” record on disk (log) (6) Resume transaction processing Yan Huang - CSCI5330 Database Implementation –Recovery

  27. <T1,A,16> <T2,B,17> <T1,commit> <T2,commit> Checkpoint <T3,C,21> Example: what to do at recovery? Redo log (disk): Crash ... ... ... ... ... ... Yan Huang - CSCI5330 Database Implementation –Recovery

  28. <T1,A,8> <T2,B,17> <T1,commit> <T2,commit> Checkpoint <T3,C,21> Example: what to do at recovery? Undo log (disk): Crash ... ... ... ... ... ... Yan Huang - CSCI5330 Database Implementation –Recovery

  29. Nonquiescent Checkingpointing • “Quiescent” checkpointing stalls DB • “Nonquiescent” checkpointing admits new transactions while checkpointing Yan Huang - CSCI5330 Database Implementation –Recovery

  30. Nonquiescent Checkpoint Rules - undo • Write and flush a log record <START CKPT(T1, …, Tk)> where T1,…,Tk are active transactions • When all T1, …, Tk have completed, write and flush a log record <END CKPT> Yan Huang - CSCI5330 Database Implementation –Recovery

  31. <T1,A,8> <T3,B,17> <CKPT(T1,T2)> <T1,commit> <T3,C,21> Example: what to do at recovery? Undo log (disk): Crash <ENDCKPT> <T2,B,12> <T2,commit> ... ... ... ... Crash after end of checkpoint Only need to undo all the incomplete transactions started after <START CKPT> Yan Huang - CSCI5330 Database Implementation –Recovery

  32. <T1,A,8> <T3,B,17> <CKPT(T1,T2)> <T1,commit> <T3,C,21> Example: what to do at recovery? Undo log (disk): Crash <T2,B,12> <T2,commit> ... ... ... ... … Crash before end of checkpoint Only need to undo all incomplete transactions started after <START CKPT> and those in <CKPT (…)> Yan Huang - CSCI5330 Database Implementation –Recovery

  33. Nonquiescent Checkpoint Rules - redo • Write and flush a log record <START CKPT(T1, …, Tk) where T1,…,Tk are active transactions • Flush all the updates of the transactions committed before <START CKPT(T1,…,Tk)> • Write and flush a log record <END CKPT> Yan Huang - CSCI5330 Database Implementation –Recovery

  34. <T1,A,8> <T3,B,17> <CKPT(T1,T2)> <T1,commit> <T3,C,21> Example: what to do at recovery? Redo log (disk): Crash <ENDCKPT> <T2,B,12> <T2,commit> ... ... ... ... Crash after end of checkpoint Only need to redo all the transactions committed after the latest <START CKPT> Yan Huang - CSCI5330 Database Implementation –Recovery

  35. <T1,A,8> <T3,B,17> <CKPT(T1,T2)> <T1,commit> <T3,C,21> Example: what to do at recovery? Redo log (disk): Crash <T2,B,12> <T2,commit> ... ... ... ... … Crash before end of checkpoint Only need to redo all the transactionscommitted after the latest successful <START CKPT> Yan Huang - CSCI5330 Database Implementation –Recovery

  36. Key drawbacks: • Undo logging: need to update immediately, increasing I/O • Redo logging: need to keep all modified blocks in memory until commit Yan Huang - CSCI5330 Database Implementation –Recovery

  37. Solution: undo/redo logging! Update  <Ti, Xid, New X val, Old X val> Yan Huang - CSCI5330 Database Implementation –Recovery

  38. Rules • Page X can be flushed before orafter Ti commit • Log record flushed before corresponding updated page (WAL) • Flush log at commit Yan Huang - CSCI5330 Database Implementation –Recovery

  39. Non-quiesce checkpoint L O G for undo Start-ckpt active TR: Ti,T2,... end ckpt ... ... ... Flush dirty buffers ... Yan Huang - CSCI5330 Database Implementation –Recovery

  40. Exampleswhat to do at recovery time? no T1 commit L O G ... T1,- a ... Ckpt T1 ... Ckpt end ... T1- b  Undo T1 (undo a,b) Yan Huang - CSCI5330 Database Implementation –Recovery

  41. Example L O G ... T1 a ... ckpt-s T1 ... T1 b ... Ckpt end ... T1 c ... T1 cmt ...  Redo T1: (redo b,c) Yan Huang - CSCI5330 Database Implementation –Recovery

  42. Exampleswhat to do at recovery time? no T1 commit L O G ... T1,- a ... Ckpt T1 ... ... T1- b  Undo T1 (all the actions) Yan Huang - CSCI5330 Database Implementation –Recovery

  43. Example L O G ... T1 a ... ckpt-s T1 ... T1 b ... ... T1 c ... T1 cmt ...  Redo T1: (redo b,c, a and the actions after last successful ckp-s) Yan Huang - CSCI5330 Database Implementation –Recovery

  44. Recovery process: • Backwards pass (end of log -> latest checkpoint start) • construct set S of committed transactions • undo actions of transactions not in S • Undo pending transactions • follow undo chains for transactions in (checkpoint active list) - S • Forward pass (latest successful checkpoint start -> end of log) • redo actions of S transactions backward pass start check- point forward pass Yan Huang - CSCI5330 Database Implementation –Recovery

  45. Recovery with Checkpoint Summary • Logging still obey the logging rules • undo, redo, undo-redo • Recovery still obey rules • Undo: undo all incomplete transactions • Redo: redo all completed transactions • Undo-redo: combined • Checkpoint provides a way to limit the transactions needing undo or redo Yan Huang - CSCI5330 Database Implementation –Recovery

  46. Summary WAL Yan Huang - CSCI5330 Database Implementation –Recovery

  47. Summary • Consistency of data • One source of problems: failures - WAL Yan Huang - CSCI5330 Database Implementation –Recovery

More Related