- Nonquiescent checkpointing:
- Performing checkpointing without stopping the DMBS from accepting new transactions
- The Nonquiescent checkpointing
algorithm for
the undo log:
1. Write a start checkpoint log record: <START CKPT(T1, T2, ..., Tk)> to log file where T1, T2, ..., Tk are the currently active transactions 2. Flush-Log (optional) 3. Wait until all of T1, T2, ..., Tk to commit or abort. (DBMS can accept new transactions !!!) 4. When all T1, T2, ..., Tk have completed: Write <END CKPT> to log file 5. Flush-Log (essential to keep the log file short)
- 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:
- Write
- <START CKPT(T1,T2)>
- Flush log
- Wait until
T1 and
T2
commit or
abort
- Write
- <END CKPT>
- Flush log
- Write
- Possible continuation:
Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <START CKPT(T1, T2)> // Flush Log <T2, C, 15> <START T3> === New transactions can start !! <T1, D, 20> <COMMIT T1> ===== T1 done <T3, E, 25> <COMMIT T2> ===== T2 done <END CKPT> // Flush Log <T3, F, 30>
- Currently: T1 and
T2 are
active:
- 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 committed transactions identify the uncommitted/aborted 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
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 committed identify the uncommitted/aborted 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 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:
- If a
transaction
T1 was
started
before the
previous check point:
The <COMMIT T1> must be written before the <END CKPT> record (according to the check point protocol):
Transaction Ti must have completed !!!
- If a
transaction
T1 was
started
before the
previous check point: