- The
ordering of
the events of
the DMBS using
a redo log
is as follows:
Database Log file ================================================= <START T> ... Write(X1) <T, X1, v1> ... Write(X2) <T, X2, v2> ... COMMIT <COMMIT T> ++++++++ FLUSH log Later on, the DBMS make updates at its convenience: ... <OUTPUT X1> ... <OUTPUT X2>
- Important property in
redo logging:
- Before the
writing of the
<COMMIT> recordno DB element can be updated !!!
This property is the result of the redo log update rule:
Transaction manager executes an operation /* ================================================================== Redo log write rule: Only update database elem's modified by committed transactions. ================================================================== */ if ( operation = OUTPUT(X) ) { /* ============================================= Database elem X was updated by transaction T ============================================= */ if ( T's state == COMMITTED ) { FLUSH log; // Write all log records to disk // including the log records belonging to T // We made sure that all updates by T can be (re)done OUTPUT(X); // (When) we make one of the updates of T to disk } else { return; // Do not write data updated by // an uncomitted transaction to disk !!! } } else { perform operation; } - Before the
writing of the
- From the
ordering of
events using a
redo log:
Database Log file ================================================= <START T> ... Write(X1) <T, X1, v1> ... Write(X2) <T, X2, v2> ... COMMIT <COMMIT T> ++++++++ FLUSH log Later on, the DBMS make updates at its convenience: ... <OUTPUT X1> ... <OUTPUT X2> - We obtain
this important property/conclussion
about the redo log:
- If the
<COMMIT T>
log record
for
transaction T
is
not found
in the
redo log (on disk):
- Transaction T has not updated any database element (on disk) !!!
Consequently:
- During a recovery from
a system failure,
we can
discard all
updates (= log records
<T,x,v>) from the
transaction T
(because their new values has not be written to the disk !!!)
- If the
<COMMIT T>
log record
for
transaction T
is
not found
in the
redo log (on disk):
- Recall:
committed transaction
- Committed transaction = a transaction T that has written the <COMMIT T> log record to disk
Example:
- Transaction T is
committed in
this situation:
- Transaction T is
not (yet) committed
in
this situation:
The COMMIT log record is in memory and not on disk !!!
- Redo log propoerty
revisited:
- In redo logging, a committed transaction may not have updated the DB element values on disk
Example:
- Therefore:
- In a database recovery operation, we must always redo the updates of committed transaction using the redo log records.
- For now, we
will assume that:
- The redo log is
append only
(for simplicaity)
(I.e.: no log record has ever been deleted)
- The redo log is
append only
(for simplicaity)
- 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 > where T is commited ) do { 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: