Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Lecture 12: Transactions: Recovery. 2 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Book Section 15.1, 15.2, 23, 24, 25.

Similar presentations


Presentation on theme: "1 Lecture 12: Transactions: Recovery. 2 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Book Section 15.1, 15.2, 23, 24, 25."— Presentation transcript:

1 1 Lecture 12: Transactions: Recovery

2 2 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Book Section 15.1, 15.2, 23, 24, 25

3 3 Recovery Type of CrashPrevention Wrong data entry Constraints and Data cleaning Disk crashes Redundancy: e.g. RAID, archive Fire, theft, bankruptcy… Buy insurance, Change jobs… System failures: e.g. power DATABASE RECOVERY Most frequent

4 4 Transactions Assumption: the database is composed of elements –Usually 1 element = 1 block –Can be smaller (=1 record) or larger (=1 relation) Assumption: each transaction reads/writes some elements

5 5 Primitive Operations of Transactions X database object t local (program) variable program (memory)memory bufferdatabase XXt INPUT(X) READ(X,t) WRITE(X,t)OUTPUT(X)

6 6 Example READ(A,t); t := t*2;WRITE(A,t); READ(B,t); t := t*2;WRITE(B,t) ActiontMem AMem BDisk ADisk B INPUT(A)888 REAT(A,t)8888 t:=t*216888 WRITE(A,t)16 88 INPUT(B)16 888 READ(B,t)816888 t:=t*216 888 WRITE(B,t)16 88 OUTPUT(A)16 8 OUTPUT(B)16

7 7 System Failures Each transaction has internal state When system crashes, internal state is lost –Don’t know which parts executed and which didn’t Remedy: use a log –A file that records every single action of the transaction

8 8 The Log An append-only file containing log records Note: multiple transactions run concurrently, log records are interleaved After a system crash, use log to: –Redo some transaction that didn’t commit –Undo other transactions that didn’t commit Three kinds of logs: undo, redo, undo/redo

9 9 Undo Logging Log records –transaction T has begun –T has committed –T has aborted –T has updated element X, and its old value was v

10 10 Undo-Logging Rules U1: If T modifies X, then must be written to disk before X is output to disk U2: If T commits, then must be written to disk only after all changes by T are output to disk Hence: OUTPUTs are done early, before the transaction commits

11 11 ActionTMem AMem BDisk ADisk BLog REAT(A,t)8888 t:=t*216888 WRITE(A,t)16 88 READ(B,t)816888 t:=t*216 888 WRITE(B,t)16 88 OUTPUT(A)16 8 OUTPUT(B)16

12 12 Recovery with Undo Log … … Question1: Which updates are undone ? Question 2: How far back do we need to read in the log ? crash

13 13 Recovery with Undo Log After system’s crash, run recovery manager Idea 1. Decide for each transaction T whether it is completed or not – …. …. = yes – …. ……. = yes – ……………………… = no Idea 2. Undo all modifications by incomplete transactions

14 14 Recovery with Undo Log Recovery manager: Read log from the end; cases: – : mark T as completed – : if T is not completed then write X=v to disk else ignore – : ignore

15 15 Recovery with Undo Log Note: all undo commands are idempotent –If we perform them a second time, no harm is done –E.g. if there is a system crash during recovery, simply restart recovery from scratch

16 16 Recovery with Undo Log When do we stop reading the log ? We cannot stop until we reach the beginning of the log file This is impractical Better idea: use checkpointing

17 17 Checkpointing Checkpoint the database periodically Stop accepting new transactions Wait until all current transactions complete Write a log record Resume transactions

18 18 Undo Recovery with Checkpointing … … (all completed) { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.com/11/3236505/slides/slide_18.jpg", "name": "18 Undo Recovery with Checkpointing … … (all completed)

19 19 Nonquiescent Checkpointing Problem with checkpointing: database freezes during checkpoint Would like to checkpoint while database is operational Idea: nonquiescent checkpointing Quiescent = being quiet, still, or at rest; inactive Non-quiescent = allowing transactions to be active

20 20 Nonquiescent Checkpointing Write a where T1,…,Tk are all active transactions Continue normal operation When all of T1,…,Tk have completed, write

21 21 Undo Recovery with Nonquiescent Checkpointing … … … During recovery, Can stop at first (provided an is seen) T4, T5, T6, plus later transactions earlier transactions plus T4, T5, T6 later transactions Q: why do we need ? Q: why do we need ? crash

22 22 Redo Logging Log records = transaction T has begun = T has committed = T has aborted = T has updated element X, and its new value is v

23 23 Redo-Logging Rules R1: If T modifies X, then both and must be written to disk before X is written to disk Hence: OUTPUTs are done late

24 24 ActionTMem AMem BDisk ADisk BLog REAT(A,t)8888 t:=t*216888 WRITE(A,t)16 88 READ(B,t)816888 t:=t*216 888 WRITE(B,t)16 88 OUTPUT(A)16 8 OUTPUT(B)16

25 25 Recovery with Redo Log … Question1: Which updates are redone ? Question 2: How far back do we need to read in the log ? crash

26 26 Recovery with Redo Log After system’s crash, run recovery manager Step 1. Decide for each transaction T whether it is completed or not – …. …. = yes – …. ……. = yes – ……………………… = no Step 2. Read log from the beginning, redo all updates of committed transactions

27 27 Nonquiescent Checkpointing Write a where T1,…,Tk are all active transactions Flush to disk all blocks of committed transactions (dirty blocks), while continuing normal operation When all blocks have been written, write

28 28 Redo Recovery with Nonquiescent Checkpointing … … … … … … Step 1: look for The last Step 2: find corresponding Step 3: redo from the earliest start of a transaction listed in, i.e. T4, T5, T6 (transactions committed earlier can be ignored) All OUTPUTs of T1 are known to be on disk crash

29 29 Comparison Undo/Redo Undo logging: –OUTPUT must be done early –If is seen, T definitely has written all its data to disk (hence, don’t need to redo) –inefficient, since changes from different transactions cannot be "accumulated" in the memory buffer Redo logging –OUTPUT must be done late –If is not seen, T definitely has not written any of its data to disk (hence there is not dirty data on disk, no need to undo) –inflexible, since changes cannot be written early to the disk and large transactions might require lots of memory buffer Would like more flexibility on when to OUTPUT: undo/redo logging (next)

30 30 Undo/Redo Logging Log records, only one change = T has updated element X, its old value was u, and its new value is v

31 31 Undo/Redo-Logging Rule UR1: If T modifies X, then must be written to disk before X is written to disk Note: we are free to OUTPUT early or late (i.e. before or after )

32 32 ActionTMem AMem BDisk ADisk BLog REAT(A,t)8888 t:=t*216888 WRITE(A,t)16 88 READ(B,t)816888 t:=t*216 888 WRITE(B,t)16 88 OUTPUT(A)16 8 OUTPUT(B)16

33 33 Recovery with Undo/Redo Log After system’s crash, run recovery manager Redo all committed transaction, top-down Undo all uncommitted transactions, bottom-up

34 34 Recovery with Undo/Redo Log crash Redo T2Undo T1, T3


Download ppt "1 Lecture 12: Transactions: Recovery. 2 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Book Section 15.1, 15.2, 23, 24, 25."

Similar presentations


Ads by Google