CS4432: Database Systems II Database Consistency and Violations? cs4432 recovery 1 Transactions, etc. • Crash recovery Chapter 17 • Concurrency control Chapter 18 • Transaction processing Chapter 19 cs4432 recovery 2 Integrity or correctness of data ? • We would like data in our database to be “accurate” ( “correct” ) at all times. EMP Name Age White 52 Green 3421 Gray 1 • How DBMS decides if data is consistent? cs4432 recovery 3 Integrity or consistency constraints • Utilize predicates data must satisfy • Examples: - cs4432 x is key of relation R x y holds in R Domain(x) = {Red, Blue, Green} no employee should make more than twice the average salary recovery 4 Definitions: • Consistent state: satisfies all constraints • Consistent DB: DB in consistent state cs4432 recovery 5 Such constraints may not capture “full correctness” Example 1 : Transaction constraints • When salary is updated, new salary > old salary • When account record is deleted, balance = 0 cs4432 recovery 6 Constraints (as we use here) may not capture “full correctness” Example 2 Database should reflect real world Reality DB cs4432 recovery 7 in any case, continue with constraints ... Observation: DB cannot be consistent always Example: Constraint : a1 + a2 +…. an = TOT Action: Deposit $100 in a2: cs4432 a2 a2 + 100 TOT TOT + 100 recovery 8 Example: a1 + a2 +…. an = TOT (constraint) Deposit $100 in a2: a2 a2 + 100 TOT TOT + 100 a2 . . 50 . . 150 . . 150 TOT . . 1000 . . 1000 . . 1100 cs4432 recovery 9 Transaction: a collection of actions that preserve consistency Consistent DB cs4432 T recovery Consistent DB’ 10 Big assumption: If T starts with consistent state AND T executes in isolation T leaves consistent state cs4432 recovery 11 Correctness (informally) • If we stop running transaction(s), DB left consistent • Each transaction sees a consistent DB cs4432 recovery 12 How can constraints be violated? • Transaction bug • DBMS bug • Hardware failure e.g., disk crash alters balance of account • Data sharing e.g.: T1: give 10% raise to programmers T2: change programmers cs4432 recovery systems analysts 13 Will not consider: • How to write correct transactions • How to write correct DBMS system • Constraint checking & repair cs4432 recovery 14 How can we prevent/fix violations? • Chapter 17: due to failures only • Chapter 18: due to data sharing only • Chapter 19: due to failures and sharing cs4432 recovery 15 Chapter 17: Recovery • First : cs4432 Failure Model recovery 16 Events cs4432 Desired Undesired recovery Expected Unexpected 17 Our failure model processor CPU memory cs4432 M D recovery disk 18 Desired events: see product manuals…. Undesired expected events: System crash - memory lost - cpu halts, resets that’s it!! Undesired Unexpected: cs4432 recovery Everything else! 19 Undesired Unexpected: Everything else! Examples: • Disk data is lost • Memory lost without CPU halt • CPU implodes wiping out universe…. • You name it … cs4432 recovery 20 Operations re Storage Hierarchy: x Memory x Disk • Input (x): block containing x memory • Output (x): block containing 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 cs4432 recovery 22 Key problem : Unfinished transaction Example: cs4432 Constraint: A=B T1: A A 2 B B2 recovery 23 T1: Read (A,t); t t2 Write (A,t); Read (B,t); t t2 Write (B,t); Output-to-Disk (A); Output-to-Disk (B);failure! A: 8 16 B: 8 16 A: 8 16 B: 8 memory cs4432 disk recovery 24 • Need atomicity: – execute all actions of a transaction or none at all cs4432 recovery 25 One solution: undo logging (immediate modification) A la Hansel and Gretel recording their navigation through forest via bread crumbs … Must have durable undo logging !!! cs4432 recovery 26 Undo logging (Immediate modification) T1: Read (A,t); t t2 Write (A,t); Read (B,t); t t2 Write (B,t); Output-to-disk (A); Output-to-disk (B); A:8 16 B:8 16 A:8 16 B:8 16 disk memory cs4432 recovery A=B <T1, start> <T1, A, 8> <T1, B, 8> <T1, commit> log 27 One “complication” : First disk, then log • Log is first written in memory • Not written to disk on every action memory A: 8 16 B: 8 16 Log: <T1,start> <T1, A, 8> <T1, B, 8> cs4432 A: 8 16 B: 8 recovery DB BAD STATE #1 Log 28 One “complication” : first log, then disk. • Log is first written in memory • Not written to disk on every action A: 8 16 B: 8 16 Log: <T1,start> <T1, A, 8> <T1, B, 8> <T1, commit> cs4432 A: 8 16 B: 8 DB Log BAD STATE #2 ... memory <T1, B, 8> <T1, commit> recovery 29 Undo logging rules (1) For every action generate undo log record (containing old value) (2) Before x is modified on disk, log records pertaining to x must be on disk (write ahead logging) (3) Before commit is written to log on disk, all writes of transaction must be reflected on disk cs4432 recovery 30 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: - write old value from log back to disk: - if Ti S then - write (X, v) - output (X) (3) For each Ti S do - write <Ti, abort> to log cs4432 recovery 31 What if failure during recovery? No problem! Undo idempotent cs4432 recovery 32 To discuss next : • Redo logging • Undo/redo logging, why both? • Checkpoints cs4432 recovery 33 Redo logging (deferred modification) T1: Read(A,t); t t2; write (A,t); Read(B,t); t t2; write (B,t); Output(A); Output(B) A: 8 16 B: 8 16 memory cs4432 output A: 8 16 B: 8 DB recovery <T1, start> <T1, A, 16> <T1, B, 16> <T1, commit> LOG 34 Redo logging rules (1) For every action, generate redo log record (containing new value) (2) Before X is modified on disk (DB), all log records for transaction that modified X (including commit) must be on disk (3) Flush log at commit cs4432 recovery 35 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) optional cs4432 recovery 36 Recovery is very, very SLOW ! Redo log: ... First Record (1 year ago) cs4432 ... ... T1 wrote A,B Committed a year ago --> STILL, Need to redo after crash!! recovery Last Crash Record 37 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 cs4432 recovery 38 Example: what to do at recovery? cs4432 recovery ... <T3,C,21> ... <T2,commit> ... <T2,B,17> ... Checkpoint ... <T1,commit> ... <T1,A,16> Redo log (disk): Crash 39 Key drawbacks: • Undo logging: Too many disk IOs • Redo logging: need to keep all modified blocks in memory until commit cs4432 recovery 40 Solution: undo/redo logging! Combine Undo/Redo Logging, namely: Update <Ti, Xid, New X val, Old X val> page X cs4432 recovery 41 Rules • Page X can be flushed before or after Ti commit • Log record flushed before corresponding updated page (WAL) • Flush at commit (log only) cs4432 recovery 42 Non-quiescent checkpoint L O G ... end ckpt ... ... ... Start-ckpt active TR: Ti,T2,... for undo cs4432 dirty buffer pool pages flushed recovery 43 Examples what to do at recovery time? no T1 commit L O G ... T1,a Undo T1 cs4432 ... Ckpt T1 ... Ckpt end ... T 1b (undo a,b) recovery 44 Example L O G ckpt-s T1 T1 ckptT1 T1 ... ... T1 ... ... ... ... ... a b end c cmt Redo T1: (redo b,c) cs4432 recovery 45 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 checkpoint start end of log) – redo actions of S transactions start checkpoint cs4432 backward pass forward pass recovery 46 Summary • Consistency of data • One source of problems: failures - Logging - Redundancy • Another source of problems: Data Sharing..... next cs4432 recovery 47