Slideshow:
Important observation on the timing in REDO logging
Important observation on the timing in REDO logging
What happened to the disk write operations made by
unsuccessful transactions ?
Consulting the ordering in the pull out:
Because the OUTPUT( ) operations can only happen after writing the <COMMIT> record
What happened to the disk write operations made by
successful (complete) transactions ?
Consulting the ordering in the pull out:
Because the OUTPUT( ) operations can only happen after writing the <COMMIT> record
What happened to the disk write operations made by
successful (complete) transactions ?
Consulting the ordering in the pull out:
Example:
What happened to the disk write operations made by
successful (complete) transactions ?
Consulting the ordering in the pull out:
Therefore:
Recovery procedure (after system failure) for the REDO log
- 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
- Prelude:
- Before we discuss
the recovery algorithm for
redo logging,
we examine the
updates made by:
- Uncommitted transactions in redo-logging
- Committed transactions in redo-logging
- Before we discuss
the recovery algorithm for
redo logging,
we examine the
updates made by:
- 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
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) !!!
- In other words:
- An uncommitted transaction T has not updated any database element (on disk) !!!
Consequently:
- During a recovery from
a system failure:
- We can discard (ignore) all updates (= log records <T,x,v>) from uncommitted transactions
(because their new values has not been 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
- Important property in
redo logging:
- In redo logging,
a committed transaction
may
not have
updated the
DB element values on
disk
(Because the goal of redo logging is to allow the DBMS to make updates (at its convenience) after the transaction has committed !!!)
Example:
- Consider this
redo log:
Notice that:
- Transaction T is
committed
(the
<COMMIT T> log record is
on disk)
- The updates (changes) made by transaction T is not yet written to disk !!!
- Transaction T is
committed
(the
<COMMIT T> log record is
on disk)
- In redo logging,
a committed transaction
may
not have
updated the
DB element values on
disk
- Conclussion:
- In a database recovery operation using
a redo log:
- We must always redo the updates of committed transaction using the redo log (<T,x,v>) records.
(Because in the worst case scenario, a committed transaction has not updated any of the database elements on disk !!!)
- In a database recovery operation using
a redo log:
- From the
above properties, the
recovery procedure used in
redo logging is:
- Discard the updates made by uncommitted transactions
- Redo all the updates made by committed transactions