Slideshow:
Understanding the use of the log file
Important observation:
Understanding the use of the log file
- consequence
It's not practical because we stop accepting new transactions to the database system while we wait !!
A simple (but not practical) log checkpointing algorithm
It's not practical because we stop accepting new transactions to the database system !!
The <CKPT> record in the log file marks the end location that we need to search when recovering
Example quiescent checkpointing algorithm
Example quiescent checkpointing algorithm
Recovery procedure adapted for a checkpointed (UNDO) log
- Fact:
- Log file records are used to recover from errors while some transactions are running (executing)
- Therefore:
- If there are
no transaction executing,
we do not need
the log file !!!!
I.e.:
- The content of
the log file is
not needed for
recovery purpose !!!
(Because there are no transactions that need to be "recovered")
- The content of
the log file is
not needed for
recovery purpose !!!
- If there are
no transaction executing,
we do not need
the log file !!!!
- The easy way
(but unpractical) to
checkpoint an
undo log:
- Wait until
the all transactions
have completed/aborted !!!
Then:
- The whole undo log can be truncated !!!
- Wait until
the all transactions
have completed/aborted !!!
- Quiescent:
- Quiescent = inactive/dormant (= no transactions are running)
- The quiescent
check point algorithm on
a undo log:
1. Make the DBMS stop accepting new transactions 2. Wait until all currently active transactions to commit or abort (and have written a <COMMIT> or <ABORT> log record) 3. Write all buffers updated by the transactions to disk 4. Write <CKPT> (checkpoint) to log ---- Marks the "useful" boundary 5. Flush the log to disk 6. Resume accepting new transactions
- 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:
- wait until T1 and T2 commit or abort
- Write all buffers updated by T1 and T2 to disk
- Write <CKPT>
- Flush log
- Possible continuation:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <T2, C, 15> <T1, D, 20> <COMMIT T1> <COMMIT T2> (Write A and B to disk --- database is now consistent) <CKPT> ------------------ Useful "boundary" (Flush log to disk) <START T3> <T3, E, 25> <T3, F, 30>If we want to truncate the log, we can remove all log records prior to the <CKPT> record
- Currently: T1 and
T2 are
active:
- How to
use a
quiescently checkpointed log for
recovery:
- We do not have to
scan the
entire (undo) log file
- The (backwards) scan can stop when we find a <CKPT> record !!!
- We do not have to
scan the
entire (undo) log file
- Example:
recovery algorithm
for undo log
using
quiescent checkpointing:
/* ================================================== Step 1: identify the uncommited transactions ================================================== */ Scan the undo log backwards until first <CKPT> record: { identify the committed identify the uncommitted/aborted transactions } /* ================================================== Step 2: undo the uncommited transactions ================================================== */ Scan the undo log backwards until first <CKPT> record: { For ( each < T, A, v > in log file ) { if ( T is uncommited ) { Update A with the (before) value v; // Undo the action !!! } } } /* ========================================================= Step 3: mark the uncommited tranasactions as failed.... ========================================================= */ For ( each T that is uncommited ) do { Write <ABORT T> to log; } Flush-Log