Slideshow:
Performing log checkpointing
without stopping
database processing operation
Remember that the goal of "log checkpointing" is:
|
Each type of log file (UNDO/REDO/etc) has a different log checkpointing algorithm
When is an
UNDO log record no longer
necessary ???
(UNDO rule U2 mandates that we must write all updated DB elements from committed transactions to disk before writing its <COMMIT> record to the UNDO log file !)
When is an
UNDO log record no longer
necessary ???
-
Explanation
Why:
The Non-quiescent checkpointing algorithm for the
UNDO log
Previous observation: all committed transactions can be (logically) removed from the UNDO log
Problem: we need a way to find out/make sure when the currently running transactions have committed/aborted
Solution: we wait...
The Non-quiescent checkpointing algorithm for the
UNDO log
The Non-quiescent checkpointing algorithm for the
UNDO log -
Timing diagram
Timing diagram of the UNDO log checkpointing algorithm:
Observation: the <BEGIN CKPT> record contains all incomplete transaction when the checkpoint operation begins
UNDO log checkpointing
- Example
UNDO log checkpointing
- Example
Actions of the UNDO log checkpointing algorithm:
UNDO log checkpointing
- Example
A possible continuation of this UNDO log:
- Non-quiescent
checkpointing:
- Non-quiescent
checkpointing =
performaining
the log checkpointing procedure
without
having to
stop the
database system
I.e.:
- We perform the log checkpointing procedure while transactions are active !!!
- Non-quiescent
checkpointing =
performaining
the log checkpointing procedure
without
having to
stop the
database system
- Observation:
- When you find a <COMMIT T>
record for
transaction T, then:
- The undo log records written on behalf of the transaction T are now unnecessary !!!
Graphically:
- Reason:
- The undo log records is
used to
roll back the
updates made by
transaction T in case
transaction T did
not write all its updates
to disk
due to
system failure
(These log records is like an insurance policy for an accident)
- The log record <COMMIT T>
is proof (= evidence) that
transaction T has
writte all its updates
onto the disk !!!
(This is enforced by UNDO log update rule #2)
- The log records
(insurance policy) are
therefore
no longer needed !!!
(And can be removed/truncated !!)
- The log records
(insurance policy) are
therefore
no longer needed !!!
- The undo log records is
used to
roll back the
updates made by
transaction T in case
transaction T did
not write all its updates
to disk
due to
system failure
- When you find a <COMMIT T>
record for
transaction T, then:
- How to to
truncate an
UNDO log:
- Find the
first uncommitted transaction
in the (undo) log:
- You can remove
everything before
this
<START Tk>
record, because:
- All log records above the first uncommitted transaction belongs to a committed transaction !!!
- Find the
first uncommitted transaction
in the (undo) log:
- The Nonquiescent checkpointing
algorithm for
the undo log:
1. Write a start checkpoint log record: <START CKPT(T1, T2, ..., Tk)> to log file where T1, T2, ..., Tk are the currently active transactions 2. Flush-Log (writes the <START CKPT> record to disk ASAP)
3. Wait until all of T1, T2, ..., Tk to commit (or abort). Undo log records for committed transactions can now be "deleted" !! (DBMS can accept new transactions during checkpointing !!!)
4. When all T1, T2, ..., Tk have completed: Write <END CKPT> to log file 5. Flush-Log (writes the <END CKPT> record to disk)
- Example:
- Currently: T1 and
T2 are
active:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10>
- Now we want to
perform a checkpoint:
- Write
- <START CKPT(T1,T2)>
- Flush log
- Wait until
T1 and
T2
commit or
abort
- Write
- <END CKPT>
- Flush log
- Write
- Possible continuation:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> // Flush Log <T2, C, 15> <START T3> === New transactions can start !! <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> <COMMIT T2> ===== T2 done <END CKPT> // Flush Log <T3, F, 30>
- Currently: T1 and
T2 are
active: