Slideshow:
How to perform recovery using
nonquiecent checkpointing using UNDO logging
After a system failure, the UNDO log file can be in one of 2 possible states:
When scanning the UNDO log file backwards, we find a <END CKPT> record first
How to perform recovery using
nonquiecent checkpointing using UNDO logging
After a system failure, the UNDO log file can be in one of 2 possible states:
When scanning the UNDO log file backwards, we find a <START CKPT> record first
UNDO logging recovery procedure for
case 1 (completed checkpoint)
Case 1 scenario:
I.e.: the last log checkpoint operation has completed successfull
UNDO logging recovery procedure for
case 1 (completed checkpoint)
Case 1 scenario:
Because the portion of the UNDO log before the <START CKPT> record contain UNDO actions of T1, T2, ..., Tk that we know have complete successfull - they are no longer needed !
UNDO logging recovery procedure for
case 1 (completed checkpoint)
Case 1 scenario:
Because some of these transaction may be incomplete - we must clean up partial updates made by these incomplete transactions
UNDO logging recovery procedure for
case 1 (completed checkpoint)
Recovery procedure for case 1 scenario: - Step 1:
This location in the log file is the last location that we need to search for UNDO records
UNDO logging recovery procedure for
case 1 (completed checkpoint)
Recovery procedure for case 1 scenario: - Step 2:
UNDO logging recovery procedure for
case 1 (completed checkpoint)
Recovery procedure for case 1 scenario: - Step 3:
UNDO logging recovery procedure for
case 1
- Example recovery
Example recovery for case 1 scenario:
UNDO logging recovery procedure for
case 1
- Example recovery
Example recovery for case 1 scenario:
UNDO logging recovery procedure for
case 1
- Example recovery
Example recovery for case 1 scenario:
Click on figure to pull out...
UNDO logging recovery procedure for
case 1
- Example recovery
Example recovery for case 1 scenario:
UNDO logging recovery procedure for
case 2 (crashed during checkpointing)
Case 2 scenario:
I.e.: the system crashed during a log checkpoint operation
UNDO logging recovery procedure for
case 2 (crashed during checkpointing)
Case 2 scenario:
I.e.: scan further back to find the <START T1> record --- this is the earliest record that we need to use.
UNDO logging recovery procedure for
case 2 (crashed during checkpointing)
Case 2 scenario:
Again: we must undo the changes made by the incomplete transactions (in the given UNDO log portion)
UNDO logging recovery procedure for
case 2 (crashed during checkpointing)
Recovery procedure for case 2 scenario: - Step 1:
This location in the UNDO log file log file is the last location that we need to search for UNDO records
UNDO logging recovery procedure for
case 2 (crashed during checkpointing)
Recovery procedure for case 2 scenario: - Step 2:
UNDO logging recovery procedure for
case 2 (crashed during checkpointing)
Recovery procedure for case 2 scenario: - Step 2:
UNDO logging recovery procedure for
case 2
- Example recovery
Example recovery for case 2 scenario:
UNDO logging recovery procedure for
case 2
- Example recovery
Example recovery for case 2 scenario:
UNDO logging recovery procedure for
case 2
- Example recovery
Example recovery for case 2 scenario:
Click on figure to pull out...
UNDO logging recovery procedure for
case 2
- Example recovery
Example recovery for case 2 scenario:
- When scanning the
log file
backwards, you can
find one of
2 possibilities:
- You find a
<END CKPT>
log record
first:
This is the case when:
- The (last) checkpoint operation has completed successfully
- You find a
<START
CKPT(T1, T2, ..., Tk)>
log record
first:
This is the case when:
- The system has crashed during the last checkpoint operation !!!!
- You find a
<END CKPT>
log record
first:
- Recovery algorithm for case 1:
- We find a <END CKPT> record
first:
- We know
(for sure)
that:
- All of the transactions T1, T2, ..., Tk have completed
Therefore, the portion of the undo log before the <START CKPT ...> log record is not necessary:
- How to
recover:
- We must
undo
all
uncommitted transactions that
has
started
after:
<START CKPT(T1, T2, ..., Tk)> recordGraphically:
- We must
undo
all
uncommitted transactions that
has
started
after:
- We find a <END CKPT> record
first:
- Recovery Algorithm for case 1:
/* ================================================== Step 1: scan the appropriate log portion and identify the uncommited transactions ================================================== */ Scan the undo log backwards until first <START CKPT(T1, T2, ..., Tk) record: { identify the uncommitted transactions
}
/* ==================================================
Step 2: undo the uncommited transactions
================================================== */
Scan the undo log backwards until first <START CKPT(T1, T2, ..., Tk)> record:
{
For ( each < T, A, v > in undo log ) do
{
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
- Example:
- Suppose the system
crashes
after completing
a checkpoint:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> <T2, C, 15> <START T3> <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> <COMMIT T2> ===== T2 done <END CKPT> // Flush Log <T3, F, 30> ++++++++++++++++++++++++++++ System crashes
- We scan backwards and
finds the
<END CKPT> record
first:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> <T2, C, 15> <START T3> <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> <COMMIT T2> ===== T2 done <END CKPT> // Flush Log <T3, F, 30> ++++++++++++++++++++++++++++ System crashes
- We scan
further backwards upto the
corresponding <START CKPT(...)>
record:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> ++++++++ Stop scanning here <T2, C, 15> <START T3> ***** T3 uncommitted ***** <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> <COMMIT T2> ===== T2 done <END CKPT> // Flush Log <T3, F, 30> ++++++++++++++++++++++++++++ System crashesWe find:
- Possible
active transactions are:
- T1, T2 (They are in the <START CKPT(T1, T2) record)
- T3 (The <START T3> log record)
- Of the possible active ones,
the following have
completed:
- T1, T2 (We found the <COMMIT Ti> record !!!)
- Possible
active transactions are:
- Therefore:
- We must undo the transaction T3 (which has not completed)
- Suppose the system
crashes
after completing
a checkpoint:
- Recovery algorithm for
case 2:
- We found a
<START CKPT(
T1, T2, ...,
Tk)> record
first:
- We know
(for sure) that:
- The only transactions
that
have not yet completed
at the start
of the check point are:
- T1, T2, ..., Tk
- How far back in the
log file do we need to
look to
find all incomplete
transactions:
- Scan the log file backward and locate the earliest <START Ti> log record
Graphically:
- Portion of the
undo log that
is needed
(= contain the
information) for
recovery:
- The only transactions
that
have not yet completed
at the start
of the check point are:
- We found a
<START CKPT(
T1, T2, ...,
Tk)> record
first:
- Recovery Algorithm for case 2:
/* ================================================== Step 1: scan the appropriate log portion and identify the uncommited transactions ================================================== */ Scan the undo log backwards until we found all <START T1>, <START T2>, ..., <START Tk> records: { identify the uncommitted transactions
}
/* ==================================================
Step 2: undo the uncommited transactions
================================================== */
Scan the undo log backwards
until we found the earliest uncommitted <START Tk> records:
{
For ( each < T, A, v > in undo log ) do
{
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
- Example:
- Suppose the system
crashed
during the
checkpoint operation:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> <T2, C, 15> <START T3> <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> ++++++++++++++++++++++++++++ System crashes
- We scan backwards and
finds the
<START CKPT(T1,
T2)> record
first:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> ++++ Find <START CKPT> first <T2, C, 15> <START T3> <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> ++++++++++++++++++++++++++++ System crashes
- We scan further backwards to
find all the
<START T1>
and
<START T2>
records:
Undo log: <START T1> ++++ Stop scaning here <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> ++++ Find <START CKPT> first <T2, C, 15> <START T3> <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> ++++++++++++++++++++++++++++ System crashesWe find:
- Possible
active transactions are:
- T1, T2 (They are in the <START CKPT(T1, T2) record)
- T3 (The <START T3> log record)
- Of the possible active ones,
the following have
completed:
- T1 (We found the <COMMIT T1> record !!!)
- Possible
active transactions are:
- Therefore:
- We must undo the transactions T2 and T3 (which have not completed)
- Suppose the system
crashed
during the
checkpoint operation:
- The furthest back we need to
scan the
log file to find:
- all of the <START T1>, <START T2>, ..., <START Tk> records
is:
- the previous <START CKPT> record
Graphically:
-
Reason:
- The
transaction T1
cannot have
started
before
the prior checkpoint:
Because transaction T1 must then have committed before the corresponding END of checkpoint:
Transaction T1 cannot be active when the next checkpoint is being taken !!!
- The
transaction T1
cannot have
started
before
the prior checkpoint: