Slideshow:
How to perform recovery using
nonquiecent checkpointing using UNDO/REDO logging
After a system failure, the REDO log file can be in one of 2 possible states:
How to perform recovery using
nonquiecent checkpointing using UNDO/REDO logging
After a system failure, the REDO log file can be in one of 2 possible states:
Key to understanding the general recovery algorithm used in
UNDO/RED logging
We need to figure out where to stop searching for uncommitted/committed transactions in the UNDO/REDO log
Limiting the search range for
uncommitted transactions in the UNDO/RED log
Transactions T1, T1, ..., Tk were uncommitted when checkpointing starts
Limiting the search range for
uncommitted transactions in the UNDO/RED log
The earliest possible uncommitted transaction in the UNDO/REDO log must be one of these:
Limiting the search range for
uncommitted transactions in the UNDO/RED log
Comment: this is not the portion of the UNDO/REDO log records that we need to use (= consult) !!
Limiting the search range for
UNDO log records in the UNDO/RED log
The portion of the log records that we need to use (= consult) to UNDO uncommitted transactions is:
The reason is given in the next slide...
Limiting the search range for
UNDO log records in the UNDO/RED log
Reason:
So we need some UNDO values stored before the checkpoint START to perform the UNDO operation
Summary: how to
UNDO incomplete transactions using
UNDO/REDO logging
Summary: how to
UNDO incomplete transactions using
UNDO/REDO logging
Limiting the
search range
for REDO log records
in the UNDO/RED log
Checkpoint has completed successfully
I.e.: the dirty data updated by all transactions have been written to disk
Therefore, we can conclude that...
Limiting the
search range
for REDO log records
in the UNDO/RED log
Therefore, we can conclude that:
(We don't need to REDO these updates anymore !!!)
Limiting the
search range
for REDO log records
in the UNDO/RED log
How to
REDO updates made by
committed transactions
in UNDO/REDO logging
How to
REDO updates made by
committed transactions
in UNDO/REDO logging
Summary:
how to
REDO committed transactions using UNDO/REDO logging
Summary:
how to
REDO committed transactions using UNDO/REDO logging
Pseudo code of the Recovery Algorithm for UNDO/REDO logging
- Step 1
Pseudo code of the Recovery Algorithm for UNDO/REDO logging
- Step 2
Pseudo code of the Recovery Algorithm for UNDO/REDO logging
- Step 2
Pseudo code of the Recovery Algorithm for UNDO/REDO logging
- Step 2
Example
Recovery Algorithm for UNDO/REDO logging
Example
Recovery Algorithm for UNDO/REDO logging
Example
Recovery Algorithm for UNDO/REDO logging
Example
Recovery Algorithm for UNDO/REDO logging
Recovery procedure:
Example
Recovery Algorithm for UNDO/REDO logging
Note:
See:
^^^^^^^
Example 2
Recovery Algorithm for UNDO/REDO logging
Example 2
Recovery Algorithm for UNDO/REDO logging
Example 2
Recovery Algorithm for UNDO/REDO logging
Example 2
Recovery Algorithm for UNDO/REDO logging
UNDO recovery: Limit the UNDO log records used:
Example 2
Recovery Algorithm for UNDO/REDO logging
UNDO recovery: Recovering using the UNDO log records:
Example 2
Recovery Algorithm for UNDO/REDO logging
REDO recovery: Recovering using the REDO log records:
Example 3
Recovery Algorithm for UNDO/REDO logging
Example 3
Recovery Algorithm for UNDO/REDO logging
Example 3
Recovery Algorithm for UNDO/REDO logging
Example 3
Recovery Algorithm for UNDO/REDO logging
UNDO recovery: Limit the UNDO log records used:
Example 3
Recovery Algorithm for UNDO/REDO logging
UNDO recovery: Recovering using the UNDO log records:
Recovering from
case 2 in UNDO/REDO logging
Portion of the UNDO/REDO log needed to UNDO the incomplete transactions:
Recovering from
case 2 in UNDO/REDO logging
Portion of the UNDO/REDO log needed to REDO the committed transactions:
Recovering from
case 2 in UNDO/REDO logging
Portion of the UNDO/REDO log needed to REDO the committed transactions:
Recovering from
case 2 in UNDO/REDO logging
Portion of the UNDO/REDO log needed to REDO the committed transactions:
- When scanning the log file
backwards, you can
find one of the
following scenarios
with the undo/redo log:
- Scaning backward in the
undo/redo log file,
you find a <END CKPT> record
first:
This is the case when:
- The last checkpoint operation
completed
successfully
Conclussion:
- All the dirty data block when check point starts have been written to disk
- 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
!!!!
Assume the worst case scenario:
- None of the dirty data block when check point starts have been written to disk
- The system has
crashed
during the last checkpoint operation
!!!!
- Scaning backward in the
undo/redo log file,
you find a <END CKPT> record
first:
- Recovery algorithm
for a
undo/redo log:
- We need to
undo
the uncommitted transactions
- Where in the undo/red log do we need to search to find the uncommitted transaction ?
- We need to
redo
the committed transactions
- Where in the undo/red log do we need to search to find the committed transaction ?
- We need to
undo
the uncommitted transactions
- Locating (limiting the range) the
uncommitted transactions
in case 1:
- The
<START CKPT> record
contains a
list of
uncommitted transactions:
-
The earliest
uncommitted transaction must be
one of
these:
- One of
T1,
T2, ...
in the
<START CKPT> record
if some of T1, T2, ... have not yet committed.
- A transaction that
started after
the <START CKPT> record
if all T1, T2, ... have committed.
- One of
T1,
T2, ...
in the
<START CKPT> record
- Therefore, the
portion of the
undo/redo log that we
need to use
to
find the
uncommitted transactions is:
- The
<START CKPT> record
contains a
list of
uncommitted transactions:
- What must be
done to
undo
all updates made
by the uncommited transactions
- The undo/redo check pointing algorithm
has written the
dirty data block
made by
uncommitted transactions
before the
check point to
disk:
Therefore:
- We will need
the (undo) log records
from
T1,
T2, ...
before the
<START CKPT>
record
to undo an
uncommitted transaction:
- The undo/redo check pointing algorithm
has written the
dirty data block
made by
uncommitted transactions
before the
check point to
disk:
- Summary:
how to
undo the
uncommitted transactions:
- Scan backback to
find the
earliest
<START Tx> record
where:
- Tx ∈ {T1, T2, ..,} and
- Tx is not committed
- Use the undo/redo log records
between the end and
the earliest
<START Tx> record
to
undo the updates
of the
uncommitted transactions :
- Scan backback to
find the
earliest
<START Tx> record
where:
- Locating (limiting the range) the
committed transactions
that need to be
re-done
in case 1:
- We find a <END CKPT> record
first:
then we know for sure:
- All updates made by
transactions that
has
committed
before the
<START CKPT(...)>
are written to
disk
during check pointing:
Therefore:
- The updates (in the log records) made by committed transactions before the <START CKPT(...)> record can be ignored
I.e.: we only need to search this this portion of the undo/redo log for REDO records:
Note:
- The search portion to locate the committed transactions is the same as the search portion to locate the uncommitted transactions !!!
- All updates made by
transactions that
has
committed
before the
<START CKPT(...)>
are written to
disk
during check pointing:
- We find a <END CKPT> record
first:
- What must be
done to
redo
all updates made
by the commited transactions
- The
updates made
committed transaction that is
before the
start of the check point
have been written to
disk
(by the undo/redo check point algorithm):
Therefore: we do not need to redo updates prior to the <START CKPT>:
- Updates made
after the
start of the check point
can still be
in memory:
(and not flushed to
disk)
Therefore: we must incorporate these updates using the undo/redo log !!!
- The
updates made
committed transaction that is
before the
start of the check point
have been written to
disk
(by the undo/redo check point algorithm):
- Summary:
how to
redo the
committed transactions
in undo-redo logging:
- Scan the
undo/redo log backwards
upto the
<START CKPT(T1,
T2, ..., Tk)>
record :
- Identify all the committed transactions
- Redo
all changes made
by the
committed transactions
starting at the
<START CKPT> log record:
- Scan the
undo/redo log backwards
upto the
<START CKPT(T1,
T2, ..., Tk)>
record :
- We can now prsent the
Recovery Algorithm
for case 1
using undo/redo logging:
/* ================================================================== Step 1: identify the committed and uncommitted transactions ================================================================== */ Scan the undo-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: undo the UNcommited transactions
*******************************************************************
**** Tx = the earliest uncommitted transaction T1, T2, ..., Tk ****
================================================================== */
Scan the undo-redo log backwards until (earliest uncomitted) <START Tx> record
{
For ( each < T, A, v, w > ) do
{
if ( T is UNcommited )
{
Update A with the (before) value v; // Undo the action !!!
}
}
}
/* ==================================================
Step 2b: redo the commited transactions
================================================== */
Scan the undo-redo log backwards until first <START CKPT(T1, T2, ..., Tk) record
Starting from this location, scan the redo log forewards
{
For ( each < T, A, v, w > ) do
{
if ( T is commited )
{
Update A with the (after) value w; // Redo 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:
- Undo portion:
- none
- 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:
- 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:
- Undo portion:
- Transaction T3
is
not committed
- There are no transaction in the
list
<START CKPT(T2)>
record that
has not comitted
T3 ∉ {T2} !!!
We can stop scanning at the <START CKPT(T2)> record !!!
Starting from the <START CKPT(T2)> record, undo all actions of 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) - Transaction T3
is
not committed
- Resulting actions:
- Update: D = 19
- Redo portion:
Starting from the <START CKPT> record, redo all actions of 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:
- 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:
- Undo portion:
- Because T2 is a transaction mention in the <START CKPT(T2)> record, we need to find the <START T2> record:
HERE marks the portion of the UNDO/REDO log used:
Undo/redo log: <START T1> <T1, A, 4, 5> <START T2> <===== HERE !! <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)
- UNDO recovery actions:
Starting 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 +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T2> ===== T2 done<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
- Undo portion:
- Suppose the
system
crashes after writing
<END CKPT> record:
- Undoing the
uncommitted transaction:
- Same as
case 1, we can use
the <START CKPT> record:
to limit the search area for uncommitted transactions to:
- Same as
case 1, we can use
the <START CKPT> record:
- Redoing the
committed transaction
is much harder
(just like the
redo-logging method):
- We find a <START
CKPT(T1, T2, ..., Tk)>
record
first:
During the checkpointing:
- The check point protocol will write the changes made by all (including the committed) transaction on disk....
Without the <END CKPT> record:
- We do not know which updates have been written to disk (and which have not !!)
Worst case scenario:
- No updates made by committed transactions have been written to disk !!!
- In the worst case scenario:
- We can not obtain
more information
from the
<START CKPT> log record !!!
- It's like:
not having the
<START CKPT>
record at all:
- We can not obtain
more information
from the
<START CKPT> log record !!!
- All we
can do is
go further back into
the redo log:
and use the recovery procedure for case 1 !!!
- We find a <START
CKPT(T1, T2, ..., Tk)>
record
first: