1. CPSC-608 Database Systems
Fall 2018
Instructor: Jianer Chen
Office: HRBB 315C
Phone:
Notes #35

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

3. Tranactions What is a transaction? What is a logic step
A sequence of actions that we want to be done as a single “logic step ”
What is a logic step
(what do we want a transaction to be)?
ACID:
Atomicity: either all steps of a transaction happen, or
none happen
Consistency: a transaction transforms a consistent DB
into a consistent DB
Isolation: execution of a transaction is isolated from
that of other transactions
Durability: if a transaction commits, its effects persist.

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. 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

6. Redo-Logging Algorithms for Redo-logging Log recording
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;

7. Checkpoint for Redo-logging……
<T1,start> …
<T2,commit>
<T3,start> …
<T4,commit> 7

8. Checkpoint for Redo-logging
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)> 8

9. Copy changes by committed Xacts to disk
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 … 9

10. Checkpoint for Redo-logging
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 10

11. Checkpoint for Redo-logging
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> 11

12. Checkpoint for Redo-logging
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> 12

13. Checkpoint for Redo-logging
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> 13

14. 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

15. 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

16. 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).

17. 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
Undo: helps guarantee
Atomicity, but transactions
commit later, more flush of
log files
Redo: helps guarantee
Durability, but requires
more main memory space
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).

18. Undo/Redo Logging
Main idea of Undo/Redo logging:
Compromising undo logging and redo logging, increasing flexibility.
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk
Undo/Redo logging rule (Rule UR): An undo/redo log record must reach disk before the corresponding change reaches disk.

19. Undo/Redo Logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Thus, when the system crashes, we can look at disk-log:
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk

20. Undo/Redo Logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Thus, when the system crashes, we can look at disk-log:
If we see <T, commit>, then all log records for T have reaches disk (although we are not sure if the corresponding changes have also reached disk), so we have all information to Redo T;
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk

21. Undo/Redo Logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Thus, when the system crashes, we can look at disk-log:
If we see <T, commit>, then all log records for T have reaches disk (although we are not sure if the corresponding changes have also reached disk), so we have all information to Redo T;
If we do not see <T, commit>, then we do not know if the log record for T is complete. However:
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk

22. Undo/Redo Logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Thus, when the system crashes, we can look at disk-log:
If we see <T, commit>, then all log records for T have reaches disk (although we are not sure if the corresponding changes have also reached disk), so we have all information to Redo T;
If we do not see <T, commit>, then we do not know if the log record for T is complete. However:
* If record <T, V, aold, anew> is not in disk, then the corresponding
change has not reached disk, yet, so we can ignore it;
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk

23. Undo/Redo Logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Thus, when the system crashes, we can look at disk-log:
If we see <T, commit>, then all log records for T have reaches disk (although we are not sure if the corresponding changes have also reached disk), so we have all information to Redo T;
If we do not see <T, commit>, then we do not know if the log record for T is complete. However:
* If record <T, V, aold, anew> is not in disk, then the corresponding
change has not reached disk, yet, so we can ignore it;
* If record <T, V, aold, anew> is in disk, then, though we do not
know if the corresponding change has reached disk, Undoing
this action is always safe.
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk

24. Undo/Redo Logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Thus, when the system crashes, we can look at disk-log:
If we see <T, commit>, then all log records for T have reaches disk (although we are not sure if the corresponding changes have also reached disk), so we have all information to Redo T;
If we do not see <T, commit>, then we do not know if the log record for T is complete. However:
* If record <T, V, aold, anew> is not in disk, then the corresponding
change has not reached disk, yet, so we can ignore it;
* If record <T, V, aold, anew> is in disk, then, though we do not
know if the corresponding change has reached disk, Undoing
this action is always safe.
Redo should go forwards while Undo should go backwards.
<T,V1, a1, b1> …
<T, commit>
New V1 = b1
<T, start>
<T,V3, a3, b3>
<T,V2, a2, b2>
<T,V4, a4, b4>
New V3 = b3
New V4 = b4
New V2 = b2
The order in which the values reach disk

25. Undo/Redo Logging Algorithms for Undo/Redo logging
Undo/Redo logging rule (UR):
Log records reach disk before the corresponding changes reach disk.
Algorithms for Undo/Redo logging
Undo/Redo log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Recovery with Undo/Redo log
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.

26. Undo/Redo-logging: Example
Log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/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
A=10
B=10
C=30
memory
disk 26

27. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
A=10
B=10
C=30
memory
disk 27

28. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
log
A=10
B=10
C=30
A=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
B=30
memory
disk 28

29. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
log
A=10
B=10
C=30
A=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
B=30
memory
disk 29

30. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
log
A=10
B=10
C=30
A=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
B=30
B=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
memory
disk 30

31. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
log
A=10
B=30
C=30
A=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
B=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
memory
disk 31

32. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
log
A=10
B=30
C=30
A=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
B=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
memory
disk 32

33. Undo/Redo: log recording
1. Add <T, start> to memory-log;
2. When T writes on A, add
<T, A, aold, anew> in memory-log;
\\ output(A) can be performed now,
\\ either before or after step 3
3. Add <T, commit> to memory-log.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
log
A=10
B=30
C=30
A=30
A=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
B=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
memory
disk 33

34. Undo/Redo: Failure Recovery
Recovery with Undo/Redo
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.
Undo/Redo: Failure Recovery
CPU
A=10
B=10
C=30
memory
disk 34

35. Undo/Redo: Failure Recovery
Recovery with Undo/Redo
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
A=10
B=10
C=30
memory
disk 35

36. crash occurs after <T, commit> is flushed to disk
Recovery with Undo/Redo
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
A=10
B=30
C=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
crash occurs after <T, commit> is flushed to disk
memory
disk 36

37. crash occurs after <T, commit> is flushed to disk
Recovery with Undo/Redo
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
A=30
B=30
C=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
<T, commit>
crash occurs after <T, commit> is flushed to disk
memory
disk 37

38. crash occurs before <T, commit> is flushed to disk
Recovery with Undo/Redo
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
A=10
B=30
C=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
crash occurs before <T, commit> is flushed to disk
memory
disk 38

39. crash occurs before <T, commit> is flushed to disk
Recovery with Undo/Redo
1. Bring disk-log to memory;
2. Scan the log forwards;
3. For T with <T,commit> in log
For <T, A, aold, anew> in log
Redo by assigning anew to A;
4. Scan the log backwards;
5. For T without <T,commit> in log
Undo by assigning aold to A.
Undo/Redo: 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, 10, 30>
read (B,t); t  t3;
write (B,t);
add-log: <T, B, 10, 30>
flush-log;
output (B);
add-log: <T, commit>
output (A);
CPU
A=10
B=10
C=30
<T, start>
<T, A, 10, 30>
<T, B, 10, 30>
crash occurs before <T, commit> is flushed to disk
memory
disk 39

40. Checkpoint for Undo/Redo logging……
<T1,start> …
<T2,commit>
<T3,start> …
<T4,commit> 40

41. Checkpoint for Undo/Redo logging
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)> 41

42. Checkpoint for Undo/Redo logging
Place a log record <Start CKPT(T1, …, Tk)>, where
T1, …, Tk are the currently active transactions;
Copy all “dirty data” in main memory to disk, this can
be due to either committed or incomplete transactions;
\\ 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 dirty data to disk …
<T5,start>
copy dirty data to disk 42

43. Checkpoint for Undo/Redo logging
Place a log record <Start CKPT(T1, …, Tk)>, where
T1, …, Tk are the currently active transactions;
Copy all “dirty data” in main memory to disk, this can
be due to either committed or incomplete transactions;
\\ 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 dirty data to disk …
<T5,start>
copy dirty data to disk
<End CKPT> 43

44. Checkpoint for Undo/Redo logging
Place a log record <Start CKPT(T1, …, Tk)>, where
T1, …, Tk are the currently active transactions;
Copy all “dirty data” in main memory to disk, this can
be due to either committed or incomplete transactions;
\\ 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, nothing beyond <Start CKPT(…)>
\\ needs Redone, but Undo still has to trace back to
\\ the earliest <Ti, start> among (T1, …, Tk). ……
<T1,start> …
<T2,commit>
<T3,start> …
<T4,commit>
<Start CKPT
(T1,T3)>
copy dirty data to disk …
<T5,start>
copy dirty data to disk
<End CKPT> 44

45. Checkpoint for Undo/Redo logging
Place a log record <Start CKPT(T1, …, Tk)>, where
T1, …, Tk are the currently active transactions;
Copy all “dirty data” in main memory to disk, this can
be due to either committed or incomplete transactions;
\\ 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, nothing beyond <Start CKPT(…)>
\\ needs Redone, but Undo still has to trace back to
\\ the earliest <Ti, start> among (T1, …, Tk).
\\ 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 dirty data to disk …
<T5,start>
copy dirty data to disk
<End CKPT> 45

46. Tranactions using logging What can affect transaction ACID?
Atomicity: either all steps of a transaction happen, or none happen
Consistency: a transaction transforms a consistent DB into a
consistent DB
Isolation: execution of a transaction is isolated from that of other
transactions
Durability: if a transaction commits, its effects persist.
using logging
What can affect transaction ACID?
Accident system failures may destroy Atomicity and Durability, thus Consistency;
Concurrent executions of transactions (which is highly desired) may affect Isolation, thus Consistency.

47. Tranactions What can affect transaction ACID?
Atomicity: either all steps of a transaction happen, or none happen
Consistency: a transaction transforms a consistent DB into a
consistent DB
Isolation: execution of a transaction is isolated from that of other
transactions
Durability: if a transaction commits, its effects persist.
Database T1 …… Tn
What can affect transaction ACID?
Accident system failures may destroy Atomicity and Durability, thus Consistency;
Concurrent executions of transactions (which is highly desired) may affect Isolation, thus Consistency.

48. DBMS Graduate Database lock table DDL language DDL complier file
administrator
DDL
complier
lock table
DDL
language
file
manager
logging &
recovery
concurrency
control
transaction
manager
database
programmer
index/file
manager
buffer
manager
query
execution
engine
DML
complier
main
memory
buffers
DML (query)
language
secondary
storage
(disks)
DBMS
Graduate Database

49. DBMS Graduate Database lock table DDL language DDL complier file
administrator
DDL
complier
lock table
DDL
language
file
manager
logging &
recovery
concurrency
control
transaction
manager
database
programmer
index/file
manager
buffer
manager
query
execution
engine
DML
complier
main
memory
buffers
DML (query)
language
secondary
storage
(disks)
DBMS
Graduate Database