Slideshow:
Short-coming of the UNDO logging algorithm
Recall the UNDO write rule U2:
Short-coming of the UNDO logging algorithm
Consequence of the UNDO write rule U2:
Short-coming of the UNDO logging algorithm
Avoiding having forced simultaneous disk operations:
Intro: REDO logging
Contrasting UNDO logging and REDO logging:
Log record formats used by REDO logging
These 3 record formats are identical to those used by UNDO logging...
Log record formats used by REDO logging
I.e.: the REDO log stores AFTER values of update operations so we can use an REDO log to repeat all updates made by a (successful) transaction
Log write rules of the REDO log
This "rule" does not provide ordering, it provide a guideline:
Reason: you cannot use log records in a REDO log to undo the updates of transactions
Therefore:
we must never
OUTPUT( ) updates
made by
incomplete transactions
- because
these updates
cannot be undone !!
- (otherwise the transaction is
no longer
atomic !!)
Log write rules of the REDO log
Timing diagram of events in REDO logging
Timing of disk write events in REDO logging:
Notice that: once the log records for transaction T are written to disk, we can make T atomic
Therefore: we can write updates made by completed transaction at a convenient time
Timing diagram of events in REDO logging
Important observation:
Pseudo code of the REDO log algorithm
Example of the REDO log algorithm
Notice the REDO log write rule forces a log flush before you can perform OUTPUT(A/B)
- Recall the
undo write rule U2:
.... /* ======================================= Undo log write rule R2 When transaction commits: Write all updates to disk ======================================= */ 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 } /* ============================== Transaction can commit now... ============================== */ 2a. write <COMMIT T> to log; 2b. FLUSH log (to disk); } ....The UNDO log write rule U2 cause the following performance bottleneck:
- The undo log write rule U2
will force
the DBMS to
write
all updated DB elements
to disk
at the moment
that a transaction
commits
- This rule will
generate
multiple
simultaneous
disk access operations
- Bursty disk access operation
usually create a
performance bottleneck
(Imagine 10 people enter a check out line at the same time ahead of you....)
- This rule will
generate
multiple
simultaneous
disk access operations
- The undo log write rule U2
will force
the DBMS to
write
all updated DB elements
to disk
at the moment
that a transaction
commits
- How to
avoid
bottle neck situation:
- Write the
updated DB elements
to disk
at the
convenience of
the Database Management System
(DBMS)
- To achieve good disk IO performance, the DBMS must be given the discretion to schedule disk write operations during less busy (= computing) periods
- Write the
updated DB elements
to disk
at the
convenience of
the Database Management System
(DBMS)
- Redo logging:
- The redo logging method
do not require
disk write operations
when a transaction
commits
- Redo logging allows the DBMS to write the updated data at its convenience
- The redo logging method
do not require
disk write operations
when a transaction
commits
- Undo logging:
- Is designed to
undo (cancel)
the
effect of
incomplete transactions
- The recovery procedure will undo the effect of uncommited transactions
- The recovery procedure will ignore the committed transactions
- Is designed to
undo (cancel)
the
effect of
incomplete transactions
- Redo logging:
- Is designed to
redo (repeat) the
effect of
complete transactions
- The recovery procedure will redo (repeat) the effect of commited transactions
- The recovery procedure will ignore the UNcommitted transactions
- Is designed to
redo (repeat) the
effect of
complete transactions
- Record types in a
redo log:
- <START T> :
- Indicates that the transaction T has started
- <COMMIT T> :
- Indicates that the
transaction T has
completed successfully
(No more actions performed by transaction T will follow !!!)
A transaction is only committed if its COMMIT log record is written to disk !!!
- Indicates that the
transaction T has
completed successfully
- <ABORT T> :
- Indicates that the
transaction T has
completed UNsuccessfully
(No more actions performed by transaction T will follow !!!)
- Indicates that the
transaction T has
completed UNsuccessfully
- <T, X, v> :
- Indicates
that the transaction T
has updated the
DB element
X.
-
Furthermore, the log record
field v contains:
- v = the
after value
(= the value after
the update operation)
of
DB element
X
(The value v can be used to redo the change made by the transaction !!!)
- The new value v can be used to redo the update operation !!!
- v = the
after value
(= the value after
the update operation)
of
DB element
X
Note:
- The record <T, X, v> is generated by a WRITE(X) action by transaction T !!!
- Indicates
that the transaction T
has updated the
DB element
X.
- <START T> :
- The redo log update
rules:
- The transaction manager can
only
perform OUTPUT( )
operations for
committed transactions
- Recall: a transaction T is committed if and only if the log contains the <COMMIT T> record
- If
the transaction manager
performs
OUTPUT(X)
that belongs to a
completed transaction
(finished, but
<COMMIT> record
not yet written to disk):
- The transaction manager must
first
write
all log reocrds
of the transaction T:
.... <T, X, v> .... (will include other updates by T) <COMMIT T> [Only then the DBMS can perform: OUTPUT(X)]to disk
I.e.:
- All log records
pertaining to the
modifcation of
DB element X must
be recorded on
disk first
(This include the <COMMIT> record !!!)
(This will ensure that the effect of a committed transaction can be repeated)
- The transaction manager must
first
write
all log reocrds
of the transaction T:
- The transaction manager can
only
perform OUTPUT( )
operations for
committed transactions
- Note:
the 2 rules stated
above is
actually
the same rule:
- Here is graphical depiction
of the
ordering of
the important update events
enforced
by the 2 rules:
Both rules will enfore the same sequence of actions
- Here is graphical depiction
of the
ordering of
the important update events
enforced
by the 2 rules:
- Redo log update rule
expressed as algorithm:
Transaction manager executes an operation /* ================================================================== Redo log write rule: Only update database elem's modified by committed transactions. When you update ANY of the modified database elem: You must write ALL redo log records of the transaction so that you can update ALL modified database elems ================================================================== */ if ( operation = OUTPUT(X) ) { /* ============================================= Database elem X was updated by transaction T ============================================= */ if ( T's state == COMMITTED ) // COMMIT record in log file on disk !! { OUTPUT(X); // OK to perform the OUTPUT operation } else if ( T's state == COMPLETED SUCCESSFFULLY ) { 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); // Then perform the requested operation } else /* Uncommitted transaction !! */ { return; // Do not write data updated by // an uncomitted transaction to disk !!! } } else { perform operation; }
- In a nutshell:
- We must write all the log records for transaction T when we update just one DB element changed by T
The reason is the following:
- The redo log
can only redo
the effect of a
transaction
(because it contains
later values)
- As long as we have not
update any DB element
changed by
a transaction T, the
DB state is
consistent
(And we do not need to write any log records for transaction T)
- But --- as
soon as we update
one DB element
changed by transaction T:
- The DB state will because
become
inconsistent
if we fail to
incorporate
all changes made by
transaction T
- Furthermore, we cannot go back to the old state using a redo log !!!
Therefore:
- Before we do OUTPUT(Xi), we must flush all log records of transaction T !!!
- The DB state will because
become
inconsistent
if we fail to
incorporate
all changes made by
transaction T
- Example:
Notice that:
- Before we
update
any DB element (A or B),
we must flush the
log records:
- Flushing the
redo log will:
- Enable us to
avoid possible
partial updates of the
DB elements (A or B, but not both)
(which will cause an inconsistent DB state !!!)
- Enable us to
avoid possible
partial updates of the
DB elements (A or B, but not both)
- Before we
update
any DB element (A or B),
we must flush the
log records:
- Observation:
- Even when we
see a
- <COMMIT T> record
in the (redo) log file on disk, we cannot be certain that:
- the updates (effects) of transaction T have been written to disk !!!
Example:
Notice that:
- The (redo) log
on disk contains
a <COMMIT T> record
- The DB elements
A and
B on
disk has
not been
updated !!!
(The updated DB elements A and B are still in the memory buffer)
- Even when we
see a
- Consequence:
- The recovery procedure will need to redo the changes made by all committed transactions !!!