Slideshow:
A simplifying assumption....
Recall: recovery procedure for REDO logging:
Pseudo code of the recovery algorithm for the REDO log
Database recovery using a REDO log
- Example
Sample of a REDO log:
Possible consistent states:
Database recovery using a REDO log
- system failed after step 11
Content of the REDO log: (right most column)
Recovery actions:
Database recovery using a REDO log
- system failed after step 11
Content of the REDO log: (right most column)
Comment:
Database recovery using a REDO log
- system failed after step 9 or 10
Content of the REDO log: (right most column)
Recovery actions:
Database recovery using a REDO log
- system failed after step 9 or 10
Content of the REDO log: (right most column)
Comment:
Database recovery using a REDO log
- system failed after step 8
Content of the REDO log: (right most column)
Comment: there are 2 possible outcomes
Database recovery using a REDO log
- system failed after step 8
Content of the REDO log: (right most column)
Recovery actions for the case when <COMMIT T> was written to log (on disk):
Database recovery using a REDO log
- system failed after step 8
Content of the REDO log: (right most column)
Recovery actions for the case when <COMMIT T> was not written to log (on disk):
Database recovery using a REDO log
- system failed before step 8
Content of the REDO log: (right most column)
Recovery actions:
- For now, we
will assume that:
- The redo log is
append only
(for simplicity)
(I.e.: no log record has ever been deleted)
- The redo log is
append only
(for simplicity)
- Recovery algorithm for redo log:
/* ================================================== Step 1: identify the commited transactions ================================================== */ Scan the redo log: { identify the committed transaction identify also the UNcommitted transaction (for writing abort records) } /* ================================================== Step 2: redo the commited transactions ================================================== */ Scan the undo log forewards: { For ( each < T, A, v > in redo log ) { if ( T is commited ) { Update A with the (after) value v; // Redo the change !!! } } } /* ========================================================= Step 3: mark the uncommited tranasactions as failed.... ========================================================= */ For ( each T that is uncommited ) do { Write <ABORT T> to log; } Flush-Log
- Example of a
redo log:
Notice that:
- There are 2 possible
consistent database states:
Consistent state 1: A = 1000, B = 2000 Consistent state 2: A = 1100, B = 1900
- There are 2 possible
consistent database states:
-
If the system
crashes
after
step
11:
Recovery:
- Committed transactions:
- T
- Action:
- Update DB element A to (new value) 1100
- Update DB element B to (new value) 1900
Comment:
- We have performed the
updates
needlessly
(Because A and B already have the new values)
- However, the database state is consistent !!!
- Committed transactions:
-
If the system
crashes
after
step
9 or 10:
Recovery:
- Committed transactions:
- T
- Action:
- Update DB element A to (new value) 1100
- Update DB element B to (new value) 1900
Comment:
- One or more of
DB lements A and
B
have not been
updated with its
new value !!!
- The recovery procedure has restored the the database back to a consistent state !!!
- Committed transactions:
-
If the system
crashes
after
step
8:
2 possibilities:
- <COMMIT T> was written to disk
- <COMMIT T> was not written to disk
Recovery if <COMMIT T> was written to disk:
- Committed transactions:
- T
- Action:
- Update DB element A to (new value) 1100
- Update DB element B to (new value) 1900
Comment:
- The
DB elements A and
B
have not been
updated with its
new value !!!
- We correctly redo the updates !!!
- Furthermore, the database is in a consistent state !!!
Recovery if <COMMIT T> was not written to disk:
- Committed transactions:
- None
- Action:
- None !!!
Comment:
- Correct, because
the system has
not flushed
the updates
made by T
to disk !!!!
- The database is in the old state before the transaction T is run .....
The database state is consistent !!!
-
If the system
crashes
before
step
9:
The <COMMIT T> record will not have been written !!!
Recovery:
- Committed transactions:
- None
- Action:
- None !!!
Comment:
- Correct, because
the system has
not flushed
the updates
made by T
to disk !!!!
- The database is in the old state before the transaction T is run .....
- Committed transactions: