Slideshow:
Terminology:
committed and
uncommitted transactions
Recovery Manager
Observation on the UNDO log to help you understand the receovery procedure
Consider the UNDO write rule U2:
Observation on the UNDO log to help you understand the receovery procedure
Consequence of the UNDO write rule U2:
Observation on the UNDO log to help you understand the receovery procedure
Consequence of the UNDO write rule U2:
If we see <COMMIT T> in the UNDO log, then we know for sure (= proof) that all of T's updates have been incorporated into the database !
The recovery algorithm for an
UNDO log
The recovery algorithm for an
UNDO log -
Pseduo code
Example recovery using an UNDO log
Example recovery using an UNDO log
The recovery procedure must recover to a consistent database state !!!
If system crashed after step 12
Recovery by undoing the uncommitted transaction:
If system crashed after step 11
2 possibilities: <COMMIT T> was written or <COMMIT T> was not written
If system crashed after step 11
2 possibilities: <COMMIT T> was written or <COMMIT T> was not written
If system crashed after step 11
2 possibilities: <COMMIT T> was written or <COMMIT T> was not written
If system crashed after step 10
<COMMIT T> is not written !
If system crashed after step 10
<COMMIT T> is not written !
If system crashed after step 8,9
If system crashed after step 8,9
If system crashed after step 8,9
If system crashed before step 7
If system crashed before step 7
- Committed (= completed successfully)
transactions:
- Committed transaction T = a transaction T where its log record COMMIT T is written onto the disk
- Uncommitted transaction:
- Uncommitted transaction = a transaction that does not have a log record COMMIT T in the log file
- Therefore:
- A COMMIT T log record (stored on disk) is the proof/evidence that the transaction T is completed
- Recovery manager:
- Recovery manager = the software component in the DBMS that is responsible for restoring the DB to a consistent state after a system failure
- Important note:
- Committed transactions must survive the system failure after the recovery !!!
- Recall
that we made
the following
assumption
keep things simple:
- The log file is
append-only
(i.e.: no log record
has been deleted)
- The log file contains
every record that
has been written
(No log records has ever been deleted)
- The log file contains
every record that
has been written
- The log file is
append-only
(i.e.: no log record
has been deleted)
- Important fact about
the undo log:
- Rule U2 says that:
- You must write all
updated
DB elements to
disk
before
you write the commit record <COMMIT T> to disk
Algorithm:
.... /* ======================================= Undo log write rule R2 ======================================= */ else if ( T's operation = OUTPUT <COMMIT T> (to disk) ) { 1. for ( each DB item D updated by transaction T ) { OUTPUT(D); // Write (new value) to disk } 2a. write <COMMIT T> to log; 2b. FLUSH log (to disk); } .... - You must write all
updated
DB elements to
disk
Consequence:
- If you
find:
<COMMIT T> log recordin the undo log, then:
- All the data that was updated by transaction T has already been written to disk !!!
- Therefore:
- We can ignore all
undo log records for
committed transactions T !!!
(Because we do not want to undo the changes made by committed transactions !!!)
- We can ignore all
undo log records for
committed transactions T !!!
- Rule U2 says that:
- How to
perform recovery from
a system failure using
an undo log:
- Identify the
uncommitted transactions
-
Undo the
actions (= write operations)
performed these
uncommitted transactions
in the reverse order in
time
- "Roll back" a transaction = undo-ing the updated made a transaction
Note:
- Roll back order is always the reversed execution order in time !!!
- Mark the
uncommited transactions as
aborted
- Identify the
uncommitted transactions
- Pseudo code of
the recovery algorithm
for undo logging:
/* ================================================== Step 1: identify the uncommited transactions ================================================== */ Scan the undo log: { identify the uncommitted/aborted transactions (I.e.: find the transactions T that: has: <START T> but no: <COMMIT T> ) } /* ============================================================= Step 2: undo the uncommited/aborted transactions in the reverse order Updates: write 1 --> write 2 --> write 3 Undos: undo write 3 --> undo write 2 --> undo write 1 ============================================================= */ Scan the undo log backwards: { For ( each < T, A, v > in undo log ) { 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 undo log:
Color-code in the loggoing example:
- The data that is inside a color column are stored on disk and will survive a system failure !!!
Notice there are 2 possible consistent database states:
-
If the system
crashes
after
step
12:
Recovery:
- Uncommitted transactions:
- None
(because <COMMIT T> is in the log file !!!)
- None
- Action:
- Nothing to do !!!
Comment:
- Correct, because the system has flushed the updated made by T to disk !!!!
- Uncommitted transactions:
-
If the system
crashes
after
step
11:
2 possibilities:
- <COMMIT T> was written
- <COMMIT T> was not written
Recovery if <COMMIT T> was written:
- Uncommitted transactions:
- None
- Action:
- None !!!
Comment:
- Correct, because the system has flushed the updated made by T to disk !!!!
Recovery if <COMMIT T> was not written:
- Uncommitted transactions:
- T !!!
- Actions caused by
records in
log:
- <T, A, 1000> ⇒ restore A back to 1000
- <T, B, 2000> ⇒ restore B back to 2000
Comment:
- The database will be
consistent...
We lost the effect of transaction T
- This cannot be avoided (because we cannot be certain whether the transaction has finished) !!!
-
If the system
crashes
after
step
10:
The <COMMIT T> record will not have been written !!!
Recovery:
- Uncommitted transactions:
- T !!!
- Actions caused by
records in
log:
- <T, A, 1000> ⇒ restore A back to 1000
- <T, B, 2000> ⇒ restore B back to 2000
Comment:
- The database will be
consistent...
- This is the correct action, because transaction T has not committed !!!!
- Uncommitted transactions:
-
If the system
crashes
after
steps
8, 9:
Then:
- A or B
(or both)
may not have been
updated
- The <COMMIT T> record will not have been written !!!
Recovery:
- Uncommitted transactions:
- T !!!
- Actions caused by
records in
log:
- <T, A, 1000> ⇒ restore A back to 1000
- <T, B, 2000> ⇒ restore B back to 2000
Comment:
- We may sometimes
needlessly overwrite
A or
B with the
same value
....
- In any case:
- The database will be in a consistent state !!!
That's all that we care !!!!
- A or B
(or both)
may not have been
updated
-
If the system
crashes
before
step
7:
Then:
- The log has
not been
written
There are no log records !!!
- However,
the database elements
A and
B
have
not been
updated !!!
- This is due to
Rule U1:
-
You must write the
log records
before updating the
database elements !!!
- This is due to
Rule U1:
Recovery:
- Uncommitted transactions:
- None !!!
- Actions caused by
records in
log:
- None !!!
Comment:
- Correct, because the database elements A and B has not been updated !!!
- The log has
not been
written