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 Nonquiescent checkpoint algorithm for an
UNDO/REDO log
Action 1 will allow us to
limit the search range of log records for
incomplete transactions
Action 3 will allow us to
limit the search range of log records for
comitted transactions
The Nonquiescent checkpoint algorithm for an
UNDO/REDO log
- Example
The Nonquiescent checkpoint algorithm for an
UNDO/REDO log
- Example
Actions performed by the UNDO/REDO checkpointing procedure:
The Nonquiescent checkpoint algorithm for an
UNDO/REDO log
- Example
Possible continuation:
- 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:
-
Uncommitted transaction
can perform
OUTPUT( ) operations
in undo-redo logging:
Conclussion:
- We must always undo the updates made by uncomitted transactions in undo-redo logging
How to limit the search range (= truncate) where to find (= identify) log records the uncomitted transactions:
- Use: <START CKPT T1, T2, ..., T2 >
The transactions T1, T2, ..., T2 are candidates for the uncomitted transactions
- The OUTPUT() operations
of
committed transactions
in undo-redo logging
can be
delayed:
Conclussion:
- We must always redo the updates made by comitted transactions in undo-redo logging
How to limit the search range (= truncate) where to find (= identify) log records the comitted transactions:
-
Incorporate the
updates
made by
all committed
transactions
(Similar to redo-logging !!!)
A simplification:
- We can safely incorporate the
updates made by the
uncommitted transactions
because:
- In UNDO/REDO logging, we can undo the uncommitted transactions if necessary !!!
- It is easier to incorporate the updates made by all transactions (don't check for commit status)
-
Uncommitted transaction
can perform
OUTPUT( ) operations
in undo-redo logging:
- 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 limit the search for uncommitted transactions to: T1, T2, ..., Tk)
3. Write: All DB elements that were updated by ALL transactions that are still in memory buffers (I.e.: write all "dirty" (updated) buffers to disk) // If checkpoint completes, then all updates made all transactions // (including the committed transactions) are flushed to disk
4. Write <END CKPT> to log Flush-Log // Write the <END CKPT> record to disk
- Note:
- The checkpointing algorithm
is similar to
the one used by
redo logging
See: click here
- The only
difference between
the checkpointing algorithm for
the redo log and
the undo/redo log is:
Redo log: 2. Write: All DB elements that were updated by committed transactions that are still in memory buffers
Undo/redo log: 2. Write: All DB elements that were updated by ALL transactions that are still in memory buffers ** These will include the DB elements that were updated ** by committed transactions !!
- The checkpointing algorithm
is similar to
the one used by
redo logging
- Example: checkpointing
a undo/redo log
- Initially: T1 and
T2 are
active:
Undo/redo log: <START T1> <T1, A, 4, 5> <START T2> <COMMIT T1> <T2, B, 9, 10>
- Now we want to
perform a checkpoint:
- Write
- <START CKPT(T2)>
(Do not include T1 because T1 has committed !!!)
- Write
the
DB element A
and B to
disk !!!
(Even when T1 has committed, the data written by T1 may not have been written to disk !)
- Write
- <END CKPT>
- Flush log
- Write
- Possible continuation:
Undo/redo log: <START T1> <T1, A, 4, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 9, 10> ============================ <START CKPT(T2)> <T2, C, 14, 15> <--+ Between here: <START T3> | **** OUTPUT(A) and OUTPUT(B) <T3, D, 19, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done <COMMIT T3> ===== T3 done (OUTPUT for T2 and T3 happens later)Comment:
- The checkpointing procedure
will output
all updated DB elements
before
writing the
<END CKPT> record
- This will simplify the recovery of the completed transactions !
Example:
- If
during a recovery
we find that
T2 has
committed
(along with an
<END CKPT> record),
then we know
for sure that:
- All updates made by T2 before the <START CKPT(..)> record has been written !!!
Therefore:
- To redo the actions by a committed transaction, we can start redo-ing the logged action from the <START CKPT(...)> record
(In contrast, in the redo log, we must start at the earliest <START Ti> record !!!
See: click here)
- The checkpointing procedure
will output
all updated DB elements
before
writing the
<END CKPT> record
- Initially: T1 and
T2 are
active: