- 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 (This will write ALL <T, x, v, w> records to disk !!!) 3. Write: All DB elements that were updated by ALL active transactions that are still in memory buffers (A.k.a.: "dirty" elements) 4. Write <END CKPT> to log Flush-Log
- 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 active transactions that are still in memory buffers
- 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(T1)>
- Write
the
DB element A
and B 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 complete 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)
- If
during a recovery
we find that
T2 has
committed
(along with an
<END CKPT> record),
then we know
for sure that:
- The checkpointing procedure
will output
all updated DB elements
before
writing the
<END CKPT> record
- Initially: T1 and
T2 are
active:
- When scanning the log file
backwards, you can
find one of the
following:
- You find a <END CKPT> record
first:
This is the case when:
- The last checkpoint operation completed successfully
- You find a <START
CKPT(T1, T2, ..., Tk)>
record
first:
This is the case when:
- The system has crashed during the last checkpoint operation !!!!
- You find a <END CKPT> record
first:
- Recovery algorithm
(in general) in a
undo/redo log:
- We need to
redo
the committed transactions
and
- We need to undo the UNcommitted transactions
- We need to
redo
the committed transactions
and
- How to
redo the
committed transactions
in case 1:
- We find a <END CKPT> record
first:
then we know for sure:
- Actions of
(all) transactions
that have
committed
before
the <START CKPT(...)>
record
need not be
redone:
because the updated DB elements have all been written to disk.
- The committed transaction that
active at
<START CKPT>
need
only be
redone
starting from
the
<START CKPT> record:
because all updates made before the <START CKPT> record has been written to disk !!!
- Actions of
(all) transactions
that have
committed
before
the <START CKPT(...)>
record
need not be
redone:
- How to
recover the
committed transactions:
- Scan upto the
<START CKPT(T1,
T2, ..., Tk)> record
- We must redo
all actions for the
committed transactions
after:
<START CKPT(T1, T2, ..., Tk)> record
- Scan upto the
<START CKPT(T1,
T2, ..., Tk)> record
- We find a <END CKPT> record
first:
- How to
undo the
UNcommitted transactions:
- We find a <END CKPT> record
first:
The uncommitted transactions can be:
- Some of T1, T2, ... in the <START CKPT> record
- Transactions that started after the <START CKPT> record
- We need to
log records for
T1,
T2, ...
to
undo the
actions
- How far back do we need to scan the log file ????
Answer:
- We will need the log records from T1, T2, ... located before the <START CKPT> record if the transaction is not committed
Answer illustrated:
Therefore, the portion of the undo/redo log that we need to use is:
- How to
undo the
UNcompleted transactions:
- Scan upto the
earliest
<START Tx>
record
- Tx is an Uncommitted transaction
- We must redo
all actions for the
UNcommitted transactions
after:
<START Tx> record
- Scan upto the
earliest
<START Tx>
record
- We find a <END CKPT> record
first:
- Recovery Algorithm for case 1:
/* ================================================== Step 1: identify the commited transactions ================================================== */ Scan the redo log backwards until first <START CKPT(T1, T2, ..., Tk) record: { identify the committed transaction // There is a COMMIT record identify the UNcommitted transaction // No COMMIT record } /* ================================================== Step 2a: redo the commited transactions ================================================== */ Scan the redo log backwards until first <START CKPT(T1, T2, ..., Tk) record Starting from this point, scan the redo log forewards { For ( each < T, A, v, w > where T is commited ) do { Update A with the (after) value w; // Redo the action !!! } } /* ================================================================= Step 2b: undo the UNcommited transactions ******************************************************************* **** Tx = the earliest uncommitted transaction T1, T2, ..., Tk **** ================================================================== */ Scan the redo log backwards until (earliest uncomitted) <START Tx> record { For ( each < T, A, v, w > where T is UNcommited ) do { 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
- Example 1:
- Suppose the
system
crashes after writing
both <COMMIT> records:
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 +++++++++++++++++++++++++++++++++++++++ System crashed.... (OUTPUT for T2 and T3 happens later)
- We scan backwards and
finds the
<END CKPT> record
first:
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 +++++++++++++++++++++++++++++++++++++++ System crashed.... (OUTPUT for T2 and T3 happens later)
- Scan further until
<START CKPT(..)> record:
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 +++++++++++++++++++++++++++++++++++++++ System crashed.... (OUTPUT for T2 and T3 happens later)Conclusion:
- Committed: T2 and T3
- Uncommitted: none...
- Recovery:
- Redo portion:
- Redo the actions of T2 and T3
- Redo all
actions of
T2 and
T3
starting from the
<START CKPT> record:
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 +++++++++++++++++++++++++++++++++++++++ System crashed.... (OUTPUT for T2 and T3 happens later)
- Resulting actions:
- Update: C = 15
- Update: D = 20
Note:
- T2
has also updated
B !!!
- Technically, we must also redo this update
- But,
B
has been updated by
the checkpoint operation !!!
- That's why we can start the redo operation at the <START CKPT> record !!!
- Undo portion:
none
- Redo portion:
- Suppose the
system
crashes after writing
both <COMMIT> records:
- Example 2:
- Suppose the
system
crashes after writing
one of the 2 <COMMIT> records:
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later)
- We scan backwards and
finds the
<END CKPT> record
first:
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later)
- Scan further and
find <START CKPT> record:
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later)Conclusion:
- Committed: T2
- Uncommitted: T3
- Recovery:
- Redo portion:
Starting from the <START CKPT> record, redo all actions for T2
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later) - Resulting actions:
- Update: C = 15
- Note:
- B has been updated by the checkpoint operation !!!
- Undo portion:
- Because T3 is not a transaction mention in the <START CKPT(T2)> record, we can stop at the <START CKPT(T2)> record !!!
Stopping from the <START CKPT(T2)> record, undo all actions for T3
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later) - Resulting actions:
- Update: D = 19
- Redo portion:
- Suppose the
system
crashes after writing
one of the 2 <COMMIT> records:
- Example 3:
- Suppose the
system
crashes after writing
<END CKPT> record:
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T2> ===== T2 done<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later)
- We scan backwards and
finds the
<END CKPT> record
first:
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T2> ===== T2 done<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later)
- Scan until
<START CKPT>:
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T2> ===== T2 done<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later)Conclusion:
- Committed: none....
- Uncommitted: T2 and T3
- Recovery:
- Redo portion: none
- Undo portion:
- Because T2 is a transaction mention in the <START CKPT(T2)> record, we need to find the <START T2> record !!!
Stopping from the <START T2> record, undo all actions for T2 and T3
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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3> ===== T3 done(OUTPUT for T2 and T3 happens later) - Resulting actions:
- Update: B = 9
- Update: C = 14
- Update: D = 19
- Redo portion: none
- Suppose the
system
crashes after writing
<END CKPT> record:
- Recovery algorithm for case 2:
- We find a <START
CKPT(T1, T2, ..., Tk)>
record
first:
- In this case:
- We do not have
any more
information
- It's like
not having the
<START CKPT>
record:
- We do not have
any more
information
- All we can do is:
and use the recovery procedure for case 1 !!!
- We find a <START
CKPT(T1, T2, ..., Tk)>
record
first: