Slideshow:
Recall: the
advantage of REDO logging
(over UNDO logging)
But REDO logging is
not completely flexible
Can we achieve complete flexibility ?
In UNDO/REDO logging, the DBMS will be able to output (= update the disk) database elements updated by both committed and uncommitted transactions at any time !!
Log record formats used by REDO logging
Log record formats used by REDO logging
Log write rule for an undo/redo log
In diagram form:
The UNDO/RED log allow the DMBS to (1) UNDO the incomplete transactions and (2) REDO the completed (= committed) transactions
The UNDO/REDO log write rule in pseudo code
Example of UNDO/REDO logging
Example of UNDO/REDO logging
Notice the UNDO/RED write rule in the UNDO/REDO log:
Example of UNDO/REDO logging
Notice the additional flexibility allowed in the UNDO/REDO log:
- Short-coming:
- In the redo logging technique
- The database system can
write (OUTPUT(X))
database element
at a convenient time
(Except when the system is performing a (redo) log checkpoint)
So: redo logging is more flexible than undo logging
- The database system can
write (OUTPUT(X))
database element
at a convenient time
-
But
redo logging
is not completely
flexible:
- The DBMS
cannot write
(e.g., free
the buffer of)
a DB element X
to disk that
has been updated by
an uncommitted transaction:
if ( operation = OUTPUT(X) ) { /* ============================================= Database elem X was updated by transaction T ============================================= */ if ( T's state == COMMITTED ) { OUTPUT(X); // OK to write } else if ( T's state == COMPLETED SUCCESSFULLY ) { FLUSH log; // Write all log records to disk // including the <COMMIT T> log record OUTPUT(X); // Then we can update disk } else { return; // Do not write data updated by // an uncomitted transaction to disk !!! } }
Another situation is:
- The same disk block contains a DB element updated by a committed transaction and also a DB element updated by a uncommitted transaction
- The DBMS
cannot write
(e.g., free
the buffer of)
a DB element X
to disk that
has been updated by
an uncommitted transaction:
- In the redo logging technique
- Question:
- Can we achieve a
higher degree of
flexibility ???
Yes:
- By combining the undo and redo log
- Can we achieve a
higher degree of
flexibility ???
- Format of a
undo/redo log record:
Undo/redo log record: < T, X, v, w > T = transaction ID X = DB element v = before value w = after valueIn other words:
- We write
both the
before value
and the
after value of
an update operation in the
log !!!
- The undo/redo log
will allow us to:
- Undo the
effect of the update
or
- Redo the effect of the update
by our own choosing !!!
- Undo the
effect of the update
or
- We write
both the
before value
and the
after value of
an update operation in the
log !!!
- Log write rule
for
an undo/redo log:
- Write
the log record:
< T, X, v, w >to disk
before writing the DB element X to disk (= OUTPUT(X))
- Write
the log record:
- Graphical summary:
- Undo/redo log update rule
expressed as algorithm:
Transaction manager executes an operation /* ================================================================== Undo/redo log write rule: First write <T, X, v, w > to disk then write X to disk ================================================================== */ if ( operation = OUTPUT(X) ) { FLUSH log; // Write all log records to disk // including the <T,X,v,w> log record // We made sure that OUTPUT(X) can be undone OUTPUT(X); else { perform operation; }
- Example:
Notice the undo-redo log write rule in action:
- Before we can perform
OUTPUT(A), we must
write the
log record
<T, A, 1000, 1100>
to disk:
This will make sure that we can undo the OUTPUT(A) action !!!
Notice the benefit of undo-redo logging:
- The DBMS can perform
OUTPUT(A)
updated by transaction T
before
the transaction T is
committed:
This give the DBMS greater flexibility to achieve optimal buffer management
- Before we can perform
OUTPUT(A), we must
write the
log record
<T, A, 1000, 1100>
to disk: