Slideshow:
Review: purpose of checkpointing a log
To understand when some log records can be remove (= deleted), we must understand their usage
We will first examine the usage of the REDO log records for aborted/committed transactions
The use of the REDO log records of
aborted transactions
The use of the REDO log records of
committed transactions
The REDO log records for
committed transactions are
used to
redo their updates
IF we
delete (remove)
these REDO log records for
committed transactions,
we cannot perform the
redo recovery !!!
How to perform log checkpointing (= remove records) on a REDO log
Using when we have learned about the usage of REDO records:
(1) Because we do not need to use REDO log records to recover the aborted transactions
(2) Because after we incorporated the changes by committed transactions, we won't need to recover them !!!
The Nonquiescent checkpoint algorithm
for a REDO log
The Nonquiescent checkpoint algorithm
for a REDO log
- Example
The Nonquiescent checkpoint algorithm
for a REDO log
- Example
Step 1: (follow with the pull out)
The Nonquiescent checkpoint algorithm
for a REDO log
- Example
Step 2: (follow with the pull out)
The Nonquiescent checkpoint algorithm
for a REDO log
- Example
Step 3: (follow with the pull out)
The Nonquiescent checkpoint algorithm
for a REDO log
- Example
Possible continuation: (follow with the pull out)
- In log checkpointing, we
want to
shorten the
log by
(logically) removing the
log records of the
completed transactions:
- Committed transactions, and
- Aborted transactions
- Facts:
-
Aborted (unsuccessful) transaction
will never perform
any OUTPUT( ) operation
in redo logging:
Conclusion:
- We can ignore (= remove) log records of the aborted trasnactions in the redo log without doing anything
- The OUTPUT() operations
of committed transactions
in redo logging
can be
delayed:
The delayed output (disk write) operation was the strength (= advantage) of redo logging over undo logging !!!
-
Aborted (unsuccessful) transaction
will never perform
any OUTPUT( ) operation
in redo logging:
- Conclussion:
- We can discard (= delete) the
log records belonging to
uncommitted transactions
- In order to
remove
the
redo records (logically)
belonging to the
committed transactions:
- We must first incorporate all updates in log records <T,X,v> made by the committed transactions to disk !!!
(Because we cannot redo the updates after we (logically) remove these log records !!!)
- We can discard (= delete) the
log records belonging to
uncommitted transactions
- Nonquiescent checkpoint algorithm:
1. Write a start checkpoint log record: <START CKPT(T1, T2, ..., Tk)> where T1, T2, ..., Tk are the currently active transactions 2. Flush-Log // Write the <START CKPT> record to disk (This will ALSO write ALL <T, x, v, w> records to disk !!!)
Updates made by committed transactions may still be in memory (not yet written on disk) 3. Incorporate updates from committed transactions: Output all DB elements that were updated by committed transactions to disk (Result: redo-log records for committed transactions can now be "deleted" !!!)
4. Write <END CKPT> to log 5. Flush-Log // Write the <END CKPT> record to disk
- Example: checkpointing
a redo log
- Initially: T1 and
T2 are
active:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> <T2, B, 10>
- Now we want to
perform a checkpoint:
- Write
- <START CKPT> log record
Result:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> <T2, B, 10> <START CKPT(T2)>
- Write
the
DB elements updated by the
committed transaction(s) (= T1)
to disk:
Redo log: <START T1> <T1, A, 5> <----- updated by a committed transaction !!! <START T2> <COMMIT T1> <----- a committed transaction !!! <T2, B, 10> <START CKPT(T2)> .... -----> Write (A,5) to disk
- Write
- <END CKPT> log record
Result:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> <T2, B, 10> <START CKPT(T2)> .... -----> Write (A,5) to disk .... <END CKPT>
- Flush log
- Write
- Possible continuation:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A,5) <T3, D, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done <COMMIT T3> ===== T3 done (OUTPUT for T2 and T3 happens later)
- Initially: T1 and
T2 are
active: