Actions are never left partially executed. Actions leave the DB in a consistent state. Actions are not affected by other concurrent actions

Transcription

1 Transaction Management Recovery (1)

2 Review: ACID Properties Atomicity Actions are never left partially executed Consistency Actions leave the DB in a consistent state Isolation Actions are not affected by other concurrent actions Durability Effects of completed actions are resilient against system failures CMPT 454: Database Systems II Recovery (1) 2/ 28

3 Integrity or Correctness of Data Data should be accurate or correct A Consistency I at all times D Examples: Name Age While 52 Green 3421 Gray 1 CMPT 454: Database Systems II Recovery (1) 3/ 28

4 Integrity or Consistency Constraints Data should satisfy the predicates Examples: The funds that Ada can transfer from her saving account to her chequing account should not exceed the total amount in her saving account. CMPT 454: Database Systems II Recovery (1) 4/ 28

5 Definition Consistent state: satisfies all constraints Consistent DB: DB in consistent state Transaction: collection of actions that preserve consistency Consistent DB Transaction T Consistent DB CMPT 454: Database Systems II Recovery (1) 5/ 28

6 Big Assumption If T starts with consistent state + T executes in isolation Tl leaves consistent t state t CMPT 454: Database Systems II Recovery (1) 6/ 28

7 Correctness (informally) If we stop running transactions, DB left consistent Each transaction sees a consistent DB CMPT 454: Database Systems II Recovery (1) 7/ 28

8 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 systems analysts CMPT 454: Database Systems II Recovery (1) 8/ 28

9 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 CMPT 454: Database Systems II Recovery (1) 9/ 28

10 Will Not Consider How to write correct transactions How to write correct DBMS Constraints checking & repair That is, solutions studied here do not need to know constraints CMPT 454: Database Systems II Recovery (1) 10 / 28

11 Chapter 17: Recovery First order of business: Failure Model Events Desired Undesired Expected Unexpected CMPT 454: Database Systems II Recovery (1) 11 / 28

12 Our Failure Model CPU processor memory M D disk CMPT 454: Database Systems II Recovery (1) 12 / 28

13 Desired events: Events See product manuals Undesired expected events: System crash Memory lost CPU halts, rests Undesired unexpected events: Everything else! Disk data is lost Memory lost without CPU halt CPU catches fire Car smashes into data center (You get the idea ) CMPT 454: Database Systems II Recovery (1) 13 / 28

14 Data Storage Second order of business: Storage Hierarchy x x Memory Disk CMPT 454: Database Systems II Recovery (1) 14 / 28

15 Operations 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 CMPT 454: Database Systems II Recovery (1) 15 / 28

16 Failure Models Undesired expected: System crash Data on disk still there on restart Undesired unexpected: Media failure Catastrophic failure Data on disks lost! CMPT 454: Database Systems II Recovery (1) 16 / 28

17 Problem 1: System Crash Transaction completed, but results only in memory A C I Durability If system crashes, effects of transaction lost Solution: don t tell user the transaction has committed until all effects are on disk! CMPT 454: Database Systems II Recovery (1) 17 / 28

18 Problem 2: System Crash Unfinished transaction Example: Constraint: A=B T1: A A 2 B B 2 CMPT 454: Database Systems II Recovery (1) 18 / 28

19 Example T1: Read (A,t); t t 2 Write (A,t); Read (B,t); t t 2 Write (B,t); Output (A); Output (B); Crash! A: 8 B: A: 8 B: 8 16 Memory Disk CMPT 454: Database Systems II Recovery (1) 19 / 28

20 Solution Need atomicity: Execute all actions of a transaction or none at all Solution: logging Atomicity C I D CMPT 454: Database Systems II Recovery (1) 20 / 28

21 One Variation: 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); Immediate Modification A: 8 B: 8 16 A: B: 8 16 <T1,start> <T1,A,8> <T1,B,8> <T1,commit> Memory Disk Log CMPT 454: Database Systems II Recovery (1) 21 / 28

22 Assumption Logging fakes atomicity by undoing writes of partially completed actions. Assumption: writing a block is atomic Atomicity of block writes is itself faked by lowlevel checks And so it goes At the bottom, there must be some intrinsically atomic action (writing a bit?) CMPT 454: Database Systems II Recovery (1) 22 / 28

23 One Complication Log is first written in memory Not written to disk on every action Memory A: 8 16 DB Bad State 1 B: 8 Data has written A: 8 16 B: 8 16 Log: <T1,start> <T1,A,8> <T1,B,8>, Log to disk, but log has not. CMPT 454: Database Systems II Recovery (1) 23 / 28

24 One Complication 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>, <T1,commit> A: 8 16 DB Bad State 2 B: 8 Commit log has <t1,b,8> <T1,commit> Log written to disk, but data has not. CMPT 454: Database Systems II Recovery (1) 24 / 28

25 Undo Logging Rules (1) For every action generate undo log record (containing i old value). (2) Before x is modified on disk, log records pertaining to x must be on disk. (3) Before commit is flushed to log, all writes of transaction must be reflected on disk. CMPT 454: Database Systems II Recovery (1) 25 / 28

26 Recovery Undo Rules: Logging Undo Rules Logging For every Ti with <Ti, start> in log: - If <Ti,commit> i or <Ti,abort> in log, do nothing - Else For all <Ti, X, v> in log: write (X, v) output (X ) Write <Ti, abort> to log IS THIS CORRECT? CMPT 454: Database Systems II Recovery (1) 26 / 28

27 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 What if failure during recovery? No problem! Undo idempotent. t CMPT 454: Database Systems II Recovery (1) 27 / 28

28 Redo logging To Discuss Undo/redo logging, why both? Real work actions Checkpoints Media failures Catastrophic t failures CMPT 454: Database Systems II Recovery (1) 28 / 28