- In log checkpointing, we
want to
shorten the
log by
removing the
completed transactions:
- Committed transactions, and
- Aborted transactions
That means:
- We want to "remove" (physically or logically) the log records of committed transactions
- Facts:
-
Aborted (unsuccessful) transaction
will never perform
a OUTPUT( ) operation
in redo logging:
Conclusion:
- We can ignore (= remove) log records of the aborted trasnactions in the redo log without doing anything
- The OUTPUT() operations
of committed transactions
in redo logging
can be
delayed:
-
Aborted (unsuccessful) transaction
will never perform
a OUTPUT( ) operation
in redo logging:
- Conclussion:
- If we want to
remove
the
redo records
of the
committed transactions:
(I.e.: we will not be able to redo the changes any longer !!!)
- We must incorporate all changes made by committed transactions to disk !!!
- If we want to
remove
the
redo records
of the
committed transactions:
- Summary of the
findings:
- To checkpoint a
redo log, we
must:
- Remove the
log records of the
aborted transactions
- Write all changes made by committed transactions to disk !!!
- Remove the
log records of the
aborted transactions
- To checkpoint a
redo log, we
must:
- Nonquiescent checkpoint algorithm:
1. Write a start checkpoint log record: <START CKPT(T1, T2, ..., Tk)> where T1, T2, ..., Tk are the currently active transactions Flush-Log (This will ALSO write ALL <T, x, v, w> records to disk !!!) 3. Write: All DB elements that were updated by committed transactions to disk 4. Write <END CKPT> to log Flush-Log
- Example: checkpointing
a redo log
- Initially: T1 and
T2 are
active:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> <T2, B, 10>
- Now we want to
perform a checkpoint:
- Write
- <START CKPT(T2)>
- Write
the
DB element A to
disk !!!
- Write
- <END CKPT>
- Flush log
- Write
- Possible continuation:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done <COMMIT T3> ===== T3 done (OUTPUT for T2 and T3 happens later)
- 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 for case 1:
- We find a <END CKPT> record
first:
We can know (for sure) that:
- All changes made by a
committed transaction T
(not one of
T1, T2, .... !!!)
)
that have committed
before the
start of the
checkpoint ---
have been
written to disk
- Notice that T1, T2, .... have not yet committed before the start of the checkpoint !!!
- The updates made by the (now committed) transactions T1, T2, .... could still be in memory !!!
Therefore, the portion of the redo log that we need to search for committed transactions with unwritten data is:
- All changes made by a
committed transaction T
(not one of
T1, T2, .... !!!)
)
that have committed
before the
start of the
checkpoint ---
have been
written to disk
- How to
recover:
- We must redo
all transactions that have
committed
after:
<START T1> record(See the above picture for reference)
- We must redo
all transactions that have
committed
after:
- 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 identify the uncommitted/aborted transactions } /* ================================================== Step 2: redo the commited transactions ================================================== */ Scan the redo log backwards until we found all <START T1>, <START T2>, ..., <START Tk> records Starting from this point, scan the redo log forewards { For ( each < T, A, v > where T is commited ) do { Update A with the (after) value v; // 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:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 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:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 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
upto
<START CKPT(T2)>
to
find all the
commit records:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done <COMMIT T3> ===== T3 done +++++++++++++++++++++++++++++++++++++++ System crashed.... (OUTPUT for T2 and T3 happens later)Result:
- Need to redo transactions T2 and T3
- We scan backwards
to find the
<START Tx>
records of all the
commit transactions:
Redo log: <START T1> <T1, A, 5> <START T2> ******** Here !!!!! <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done <COMMIT T3> ===== T3 done +++++++++++++++++++++++++++++++++++++++ System crashed.... (OUTPUT for T2 and T3 happens later)From the line marked by Here, scan forward and redo all actions of T2 and T3
- Suppose the
system
crashes after writing
both <COMMIT> records:
- Note:
- To limit the scanning to redo the actions of committed transaction, we will discuss log record pointers later
- Example 2:
(losing a
committed transaction)
- Suppose the
system
crashes after writing
only one <COMMIT> record:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 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:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 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
upto
<START CKPT(T2)>
to
find all the
commit records:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3>===== T3 done (OUTPUT for T2 and T3 happens later)Result:
- Need to redo transactions T2 (only !!!)
- We scan backwards
to find the
<START Tx>
records of all the
commit transactions:
Redo log: <START T1> <T1, A, 5> <START T2> ******** Here !!!!! <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ <END CKPT> // Flush Log <COMMIT T2> ===== T2 done +++++++++++++++++++++++++++++++++++++++ System crashed....<COMMIT T3>===== T3 done (OUTPUT for T2 and T3 happens later)From the line marked by Here, scan forward and redo all actions of T2
- Finally, we write an
abort record for
T3:
<ABORT T3>
- Suppose the
system
crashes after writing
only one <COMMIT> record:
- Note:
- A committed transaction (T3)
can be voided if
its
<COMMIT> record
is not written to
the redo log !!!
- To minimize this phenomenon, the redo log is flushed when a <COMMIT> record is written....
- A committed transaction (T3)
can be voided if
its
<COMMIT> record
is not written to
the redo log !!!
- 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:
- Example:
- Suppose the
system
crashes before
the check point ends:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ +++++++++++++++++++++++++++++++++++++++ System crashed....<END CKPT>// Flush Log<COMMIT T2>===== T2 done<COMMIT T3>===== T3 done (OUTPUT for T2 and T3 happens later)
- We scan backwards and
finds the
<START CKPT> record
first:
Redo log: <START T1> <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> ******** <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ +++++++++++++++++++++++++++++++++++++++ System crashed....Search back to last <END CKPT> record (or to the start of the log file):
Redo log: <START T1> <--------- <T1, A, 5> <START T2> <COMMIT T1> ==== T1 done <T2, B, 10> ============================ <START CKPT(T2)> ******** <T2, C, 15> <--+ Between here: <START T3> | **** OUTPUT(A) <T3, D, 20> <--+ +++++++++++++++++++++++++++++++++++++++ System crashed....Result:
- Need to redo transactions T1
Comment:
- This action is correct, because the OUTPUT operation of T1 may not have been executed !!!
- Suppose the
system
crashes before
the check point ends:
- Recall the
recovery algorithm for
an redo log:
/* ================================================== Step 1: identify the commited transactions ================================================== */ Scan the redo log backwards until first <START CKPT(T1, T2, ..., Tk) record: { identify the committed identify the uncommitted/aborted transactions } /* ================================================== Step 2: redo the commited transactions ================================================== */ Scan the redo log backwards until we found all <START T1>, <START T2>, ..., <START Tk> records Starting from this point, scan the redo log forewards { For ( each < T, A, v > where T is commited ) do { Update A with the (after) value v; // 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 - We can find
all <START T1>,
<START T2>, ..., <START Tk>
records
- The scanning can be
limited if we
include the
position of
all <START T1>,
<START T2>, ..., <START Tk>
records
in the
<START CKPT> record:
