Undo logging

Slideshow:

Operating assumption to simplify the presentation

The UNDO log

The record types in the UNDO log - part 1

The record types in the UNDO log - part 2

The UNDO log write rule U1

The UNDO log write rule U2

Summary of the UNDO log write rules

Remember that a transaction must either (1) do no updates or (2) do all updates

UNDO rule U1 ensures that incomplete transactions do no updates by rolling back updates

UNDO rule U2 ensures that completed transactions will do all updates

The UNDO logging pseudo code

Reminder: the flush log operation

Example of a sequence of primitive operations using UNDO logging rules

Note:

Comment: requirement imposed by UNDO write rule U1

Comment: requirement imposed by UNDO write rule U2

❮ ❯

Assumption

Assumption:

For simplicity, we assume that the log file is append-only
In other words:
This assumption will make the logging technique easier to explain

Note:

Later, we will discuss (log) checkpoint that will truncate the log file....
(This will make the topic of log checkpointing into a separate topic and make the discussion more modular)

The undo log records

Undo logging:

Record types in an undo-log:

<START T> :
<COMMIT T> :
<ABORT T> :

<T, X, v> :

Indicates that the transaction T has updated the DB element X.

Furthermore, the log record field v contains:

v = the former value (= the value before the update operation) of DB element X
(The value v can be used to undo the change made by the transaction !!!)

Note:

The record <T, X, v> is generated by a WRITE(X) action by transaction T !!!

Rules for writing an undo log

The undo logging rules:

Rule U1:

If a transaction T performs OUTPUT(X) (to write X to disk):

The Transaction manager must first:

Write log record <T, X, v> to disk

before writing the new value of X to disk using

OUTPUT(X)

This ordering of actions will guarantee that:

We can always undo the change made by OUTPUT(X) using the before value v in a log record on disk !!!

Rule U2:

If a transaction T write a <COMMIT T> log record to disk:

The Transaction manager must write
before writing

Because once the <COMMIT T> log record has been recorded on disk, we will not (= cannot) undo the transaction

Therefore:

The database must write all the new values to disk to remain consistent !!!

Undo write rules expressed as algorithm:

Transaction manager executes an operation /* ======================================= Undo log write rule R1 ======================================= */ if ( operation = OUTPUT(X) (to disk) ) { 1. FLUSH log (on disk); // This will OUTPUT <T, X, v> to disk 2. OUTPUT(X) (on disk); } /* ======================================= Undo log write rule R2 ======================================= */ else if ( operation = OUTPUT <COMMIT T> (to disk) ) { 1. for ( each DB item D updated by transaction T ) { OUTPUT(D); // Write (new value) to disk } 2a. write <COMMIT T> to log; 2b. FLUSH log (to disk); } else { Execute operation // No further action needed }

The Flush-log operation
- Recall the log flush operation will force the log records in memory to be written to disk:

Example undo logging

Example:

Note:

The data on disk are high lighted in yellow/gold !!!
When the system crashes:

Comments:

Notice the undo write rule 1:

Write undo log records (<T,A,1000>, <T,B,2000>) before writing database elements (OUTPUT(A), OUTPUT(B))

requires the following ordering of action:

Notice that:

At time 9 and beyond, we can undo the operations of the transaction in the case that the updates made by the transaction is incomplete (due to system crash)

Notice the undo write rule 2:

Write all database elements (OUTPUT(A), OUTPUT(B)) before writing the COMMIT log record

requires the following ordering of action:

Notice that:

At time 12 and beyond, we can know for sure that all updates made by the transaction are written to the disk
I.e.: the transaction is atomic !!!