Database Systems Logging Strategies: Redo-Logging Overview

csce 608 database systems n.w
1 / 73
Embed
Share

Learn about Redo-logging in database systems, its format, main idea, and importance in ensuring Atomicity and Durability. Dive into the key concepts and strategies for coping with system failures effectively.

  • Database Systems
  • Redo-Logging
  • System Failures
  • Logging Strategies
  • Atomicity
rayaanacharya
shel_3 Follow

Uploaded on | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

Download Presentation

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript

  1. CSCE-608 Database Systems Spring 2025 Instructor: Jianer Chen Office: PETR 428 Phone: 845-4259 Email: chen@cse.tamu.edu Notes 36: Redo-logging, Undo/Redo logging

  2. lock table DDL complier concurrency control file logging & recovery manager User-1 DDL User-2 transaction manager User-3 index/file manager buffer manager query execution engine DML User-n DML complier main memory buffers secondary storage (disks) DBMS

  3. Coping with System Failures Therefore, the logging strategy must be carefully designed to ensure Atomicity and Durability. If you are going to be in the logging business, one of the things that you have to do is to learn about heavy equipment. Robert VanNatta, Logging History of Columbia County We will study three logging strategies: Undo-logging Redo-logging Undo/Redo-logging

  4. Coping with System Failures Therefore, the logging strategy must be carefully designed to ensure Atomicity and Durability. If you are going to be in the logging business, one of the things that you have to do is to learn about heavy equipment. Robert VanNatta, Logging History of Columbia County We will study three logging strategies: Undo-logging Redo-logging Undo/Redo-logging

  5. Redo-Logging The format of the Redo-log: <T, start> <T, A, anew> <T, B, bnew> <T, commit> (or <T, abort>) transaction T starts transaction T wrote on A/B, and A/B had an new value anew/bnew transaction T commits/abort

  6. Redo-Logging The format of the Redo-log: <T, start> <T, A, anew> <T, B, bnew> <T, commit> (or <T, abort>) transaction T starts transaction T wrote on A/B, and A/B had an new value anew/bnew transaction T commits/abort Undo-logging uses OLD values

  7. Redo-Logging The format of the Redo-log: <T, start> <T, A, anew> <T, B, bnew> <T, commit> (or <T, abort>) transaction T starts transaction T wrote on A/B, and A/B had an new value anew/bnew transaction T commits/abort Main idea of Redo-logging: If the Redo-log record <T, commit> has not reached disk, then no changes made by T have reached disk.

  8. Redo-Logging The format of the Redo-log: <T, start> <T, A, anew> <T, B, bnew> <T, commit> (or <T, abort>) transaction T starts transaction T wrote on A/B, and A/B had an new value anew/bnew Compare with Undo: If <T, commit> reaches disk, then all changes by T have reached disk transaction T commits/abort Main idea of Redo-logging: If the Redo-log record <T, commit> has not reached disk, then no changes made by T have reached disk.

  9. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Redo-logging rule (Rule R1): The entire Redo-log for T (including <T, commit>) reaches disk before any change by T reaches disk <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 New V1 New V2 New V3

  10. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Redo-logging rule (Rule R1): The entire Redo-log for T (including <T, commit>) reaches disk before any change by T reaches disk <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 Remarks: 1. Log-record of all results of T reaches disk before T s costly disk I/O s; New V1 New V2 New V3

  11. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Redo-logging rule (Rule R1): The entire Redo-log for T (including <T, commit>) reaches disk before any change by T reaches disk <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 Remarks: 1. Log-record of all results of T reaches disk before T s costly disk I/O s; 2. One flush-log is sufficient for the entire T-log; New V1 New V2 New V3

  12. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Redo-logging rule (Rule R1): The entire Redo-log for T (including <T, commit>) reaches disk before any change by T reaches disk <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 Remarks: 1. Log-record of all results of T reaches disk before T s costly disk I/O s; 2. One flush-log is sufficient for the entire T-log; 3. Drawback: needs main memory space to hold intermediate results New V1 New V2 New V3

  13. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Thus, when the system crashes, we can look at disk-log: <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 New V1 New V2 New V3

  14. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Thus, when the system crashes, we can look at disk-log: If we do not see <T, commit>, by R1, we know that none of the changes made by T has reached disk, yet. Thus, we can ignore T; <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 New V1 New V2 New V3

  15. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Thus, when the system crashes, we can look at disk-log: If we do not see <T, commit>, by R1, we know that none of the changes made by T has reached disk, yet. Thus, we can ignore T; If we see <T, commit>, then all records for T have reached disk, although we do not know which also have their corresponding changes reach disk. To ensure atomicity, we must Redo T; <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 New V1 New V2 New V3

  16. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Thus, when the system crashes, we can look at disk-log: If we do not see <T, commit>, by R1, we know that none of the changes made by T has reached disk, yet. Thus, we can ignore T; If we see <T, commit>, then all records for T have reached disk, although we do not know which also have their corresponding changes reach disk. To ensure atomicity, we must Redo T; When Redoing T, for each <T, V, anew> we see, we are unsure if the new value anew of V has reached disk. However, Redoing the action (i.e., assigning the new value anew to V) is always safe. <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 New V1 New V2 New V3

  17. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Thus, when the system crashes, we can look at disk-log: If we do not see <T, commit>, by R1, we know that none of the changes made by T has reached disk, yet. Thus, we can ignore T; If we see <T, commit>, then all records for T have reached disk, although we do not know which also have their corresponding changes reach disk. To ensure atomicity, we must Redo T; When Redoing T, for each <T, V, anew> we see, we are unsure if the new value anew of V has reached disk. However, Redoing the action (i.e., assigning the new value anew to V) is always safe. The Redo should follow the forward order recorded in the log. <T, start> The order in which the values reach disk <T,V1, a1> <T,V2, a2> <T,V3, a3> <T,V4, a4> <T, commit> New V4 New V1 New V2 New V3

  18. Redo-Logging Main idea of Redo-logging: If <T, commit> is not in disk, then no changes made by T have reached disk. Algorithms for Redo-logging Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A;

  19. Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Redo-logging: Example T1: A A 3 B B 3 read (A,t); t t 3; write (A,t); read (B,t); t t 3; write (B,t); output (A); output (B); CPU C=30 B=10 A=10 memory disk 19 19

  20. Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Redo-logging: log recording T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=10 memory disk 20 20

  21. Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Redo-logging: log recording T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 A=30 <T, start> <T, A, 30> <T, B, 30> B=30 memory disk 21 21

  22. Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Redo-logging: log recording T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> B=30 memory disk 22 22

  23. Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Redo-logging: log recording T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 A=30 <T, start> <T, A, 30> <T, B, 30> <T, start> <T, A, 30> <T, B, 30> <T, commit> <T, commit> B=30 <T, start> <T, A, 10> <T, B, 10> memory disk 23 23

  24. Log recording 1. Add <T, start> to memory-log; 2. When T writes on A, add <T, A, anew> in memory-log (no output(A) is allowed yet); 3. Add <T, commit> to memory-log; 4. Flush memory-log to disk; 5. Perform output(A) for disk elements A that were written by T. Redo-logging: log recording T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 A=30 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> B=30 B=30 <T, start> <T, A, 10> <T, B, 10> <T, commit> <T, commit> <T, start> <T, A, 30> <T, B, 30> memory disk 24 24

  25. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery CPU C=30 B=10 A=10 memory disk 25 25

  26. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=10 memory disk 26 26

  27. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=30 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> crash occurs after this point, memory disk 27 27

  28. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=30 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> crash occurs after this point, memory disk 28 28

  29. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> crash occurs at this point, memory disk 29 29

  30. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=30 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> crash occurs at this point, memory disk 30 30

  31. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=10 <T, start> <T, A, 30> <T, B, 30> <T, commit> crash occurs at this point, memory disk 31 31

  32. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=30 A=30 <T, start> <T, A, 30> <T, B, 30> <T, commit> crash occurs at this point, memory disk 32 32

  33. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=10 crash occurs before <T, commit> reaches disk memory disk 33 33

  34. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 <T, start> <T, A, 30> <T, B, 30> <T, commit> <T, start> <T, A, 30> <T, B, 30> crash occurs before <T, commit> reaches disk memory disk 34 34

  35. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 <T, start> <T, A, 30> <T, B, 30> <T, commit> <T, start> <T, A, 30> <T, B, 30> <T, abort> crash occurs before <T, commit> reaches disk memory disk 35 35

  36. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 log B=10 A=10 <T, start> <T, A, 30> <T, B, 30> <T, start> <T, A, 30> crash occurs before <T, commit> reaches disk memory disk 36 36

  37. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=10 <T, start> <T, A, 30> crash occurs before <T, commit> reaches disk memory disk 37 37

  38. Recovery with Redo-log 1. Bring disk-log to memory; 2. Scan the log forwards; 3. If <T, commit> is not in log Then Ignore T; \\but write <T, abort> to disk-log 4. For T with <T, commit> in log For each <T, A, anew> in log Redo by assigning anew to A; Redo-logging: Failure Recovery T: A A 3 B B 3 add-log: <T, start> read (A,t); t t 3; write (A,t); add-log: <T, A, 30> read (B,t); t t 3; write (B,t); add-log: <T, B, 30> add-log: <T, commit> flush-log; output (A); output (B); CPU C=30 B=10 A=10 <T, start> <T, A, 30> <T, abort> crash occurs before <T, commit> reaches disk memory disk 38 38

  39. Checkpoint for Redo-logging log <T1,start> <T2,commit> <T3,start> <T4,commit> 39 39

  40. Checkpoint for Redo-logging log Place a log record <Start CKPT(T1, , Tk)>, where T1, , Tk are the currently active transactions; <T1,start> <T2,commit> <T3,start> <T4,commit> <Start CKPT (T1,T3)> 40 40

  41. Checkpoint for Redo-logging log Place a log record <Start CKPT(T1, , Tk)>, where T1, , Tk are the currently active transactions; Copy all elements in main memory that were written by committed transactions to disk; <T1,start> <T2,commit> <T3,start> <T4,commit> <Start CKPT (T1,T3)> Copy changes by committed Xacts to disk 41 41

  42. Checkpoint for Redo-logging log Place a log record <Start CKPT(T1, , Tk)>, where T1, , Tk are the currently active transactions; Copy all elements in main memory that were written by committed transactions to disk; \\ at the meanwhile, the system can continuously \\ accept new transactions (non-quiescent) <T1,start> <T2,commit> <T3,start> <T4,commit> <Start CKPT (T1,T3)> Copy changes by committed Xacts to disk <T5,start> Copy changes by committed Xacts to disk 42 42

  43. Checkpoint for Redo-logging log Place a log record <Start CKPT(T1, , Tk)>, where T1, , Tk are the currently active transactions; Copy all elements in main memory that were written by committed transactions to disk; \\ at the meanwhile, the system can continuously \\ accept new transactions (non-quiescent) When step 2 is done, place a log record <End CKPT>. <T1,start> <T2,commit> <T3,start> <T4,commit> <Start CKPT (T1,T3)> Copy changes by committed Xacts to disk <T5,start> Copy changes by committed Xacts to disk <End CKPT> 43 43

  44. Checkpoint for Redo-logging log Place a log record <Start CKPT(T1, , Tk)>, where T1, , Tk are the currently active transactions; Copy all elements in main memory that were written by committed transactions to disk; \\ at the meanwhile, the system can continuously \\ accept new transactions (non-quiescent) When step 2 is done, place a log record <End CKPT>. \\ at this point, all log records before the earliest \\ <Ti, start> among (T1, , Tk) can be ignored <End CKPT> <T1,start> <T2,commit> <T3,start> <T4,commit> <Start CKPT (T1,T3)> Copy changes by committed Xacts to disk <T5,start> Copy changes by committed Xacts to disk <End CKPT> 44 44

  45. Checkpoint for Redo-logging log Place a log record <Start CKPT(T1, , Tk)>, where T1, , Tk are the currently active transactions; Copy all elements in main memory that were written by committed transactions to disk; \\ at the meanwhile, the system can continuously \\ accept new transactions (non-quiescent) When step 2 is done, place a log record <End CKPT>. \\ at this point, all log records before the earliest \\ <Ti, start> among (T1, , Tk) can be ignored \\ if crash occurs between <Start CKPT(T1, , Tk)> \\ and <End CKPT>, then look for a previous \\ <End CKPT> <End CKPT> <T1,start> <T2,commit> <T3,start> <T4,commit> <Start CKPT (T1,T3)> Copy changes by committed Xacts to disk <T5,start> Copy changes by committed Xacts to disk <End CKPT> 45 45

  46. Coping with System Failures Therefore, the logging strategy must be carefully designed to ensure Atomicity and Durability. If you are going to be in the logging business, one of the things that you have to do is to learn about heavy equipment. Robert VanNatta, Logging History of Columbia County We will study three logging strategies: Undo-logging Redo-logging Undo/Redo-logging

  47. Coping with System Failures Therefore, the logging strategy must be carefully designed to ensure Atomicity and Durability. If you are going to be in the logging business, one of the things that you have to do is to learn about heavy equipment. Robert VanNatta, Logging History of Columbia County We will study three logging strategies: Undo-logging Redo-logging Undo/Redo-logging

  48. Coping with System Failures Therefore, the logging strategy must be carefully designed to ensure Atomicity and Durability. If you are going to be in the logging business, one of the things that you have to do is to learn about heavy equipment. Robert VanNatta, Logging History of Columbia County We will study three logging strategies: Undo-logging Redo-logging Undo/Redo-logging

  49. Undo/Redo Logging The format of the Undo/Redo log: <T, start> <T, A,aold,anew> <T, B,bold,bnew> <T, commit> (or <T, abort>) transaction T starts transaction T wrote on A/B, both old and new values are recorded transaction T commits/abort

  50. Undo/Redo Logging The format of the Undo/Redo log: <T, start> <T, A,aold,anew> <T, B,bold,bnew> <T, commit> (or <T, abort>) transaction T starts transaction T wrote on A/B, both old and new values are recorded transaction T commits/abort Main idea of Undo/Redo logging: Increase flexibility and compromise undo logging and redo logging (at the expense of using more space).

Related


No related presentations.

More Related Content