- Previously we made the following
assumption:
- The log is never truncated
This assumption simplifies the discuss on recovery
- We can examine all transactions and determine which ones have committed
- Problem with append-only
log:
- Too large
We need to truncate the log from time to time....
- In log checkpointing, we
shorten the
log file by
"removing" the
log records from
completed transactions:
- Committed transactions (= completed successfull), and
- Aborted transactions (= completely unsuccessfully)
- Comment:
- I put "remove"
on quotes because
log checkpointing will
remote log records
logically:
- We will write a
LOG CHECK POINT
log record into
the log file
- Some log records before this LOG CHECK POINT record will not be examined in the recovery procedure
- We will write a
LOG CHECK POINT
log record into
the log file
See next item of discussion
- I put "remove"
on quotes because
log checkpointing will
remote log records
logically:
- 2 ways to
delete
records from a
log file:
- Physically:
- The log records are actually deleted from the log file
- Logically:
- The log file is
marked with a
special
"check point" record
- Some portion of the log file will be discarded (= ignored when we use it in recovery
- The log file is
marked with a
special
"check point" record
- Physically:
- In practical,
all log records are
kept for the
purpose of:
- accounting !!!
(Especially in banking transactions !!!)
- accounting !!!
- Log checkpointing
in practice:
- A special
check point (log) record is
written into
the log file
- Recovery operations will
mostly use the
portion of the
log file that is
written
after the
check point record
(I wrote "mostly use" because you will see later that we will also need to use a (small) portion of the log file before the CHCK POINT record in recovery)
- A special
check point (log) record is
written into
the log file
- 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
unused to
roll back the
actions/operations of
transaction T in case
transaction T did
not complete 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
completed successfully
- The log records (insurance policy) is no longer needed because the event has passed
- The undo log records is
unused to
roll back the
actions/operations of
transaction T in case
transaction T did
not complete 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:
- How to
apply the
undo log truncation
technique:
- Quiescent check pointing
- Non-quiescent check pointing
- 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 "receovered")
- 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. Flush the log to disk 4. Write <CKPT> (checkpoint) to log ---- Marks the "useful" boundary 5. Flush the log 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 <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> <CKPT> ------------------ Useful "boundary" <START T3> <T3, E, 25> <T3, F, 30>If we want to trancate an undo log, we can remove all log record prior to the <CKPT> record
- Currently: T1 and
T2 are
active:
- Result:
- Key difference:
- 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
- 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