The most widely used structure for recording database modifications is the log.

The log is a sequence of log records and maintains a history of all update activities in the database.

There are several types of log records.

An update log record describes a single database write:

i. Transactions identifier.

ii. Data-item identifier.

iii. Old value.

iv. New value.

Whenever a transaction performs a write, it is essential that the log record for that write be created before the database is modified.

Once a log record exists, we can output the modification that has already been output to the database.

Also we have the ability to undo a modification that has already been output to the database, by using the old-value field in the log records.

For log records to be useful for recovery from system and disk failures, the log must reside on stable storage.

However, since the log contains a complete record of all database activity, the volume of data stored in the log may become unreasonable large.

Two approaches using logs:

i. Deferred database modification

ii. Immediate database modification.

Deferred Database Modification:

• The deferred-modification technique ensures transaction atomicity by recording all database modifications in the log, but deferring all write operations of a transaction until the transaction partially commits (i.e., once the final action of the transaction has been executed).

• Then the information in the logs is used to execute the deferred writes. If the system crashes or if the transaction aborts, then the information in the logs is ignored.

• Assume that transactions execute serially

• Transaction starts by writing <tistart> record to log.

• A write(X) operation results in a log record<ti,x,v> being written, where V is the new value for X. Note: old value is not needed for this scheme.

• The write is not performed on X at this time, but is deferred.

• When Ti partially commits,<ticommit> is written to the log.

• Finally, the log records are read and used to actually execute the previously deferred writes.

• During recovery after a crash, a transaction needs to be redone if and only if both<tistart> and ,<ticommit> are there in the log.

• Redoing a transaction Ti( redoTi) sets the value of all data items updated by the transaction to the new values.

• Crashes can occur while the transaction is executing the original updates, or while recovery action is being taken.

Immediate Database Modification:

• The immediate-update technique allows database modifications to be output to the database while the transaction is still in the active state.

• These modifications are called uncommitted modifications. In the event of a crash or transaction failure, the system must use the old-value field of the log records to restore the modified data items.

• Recovery procedure has two operations instead of one:

o Undo(Ti) restores the value of all data items updated by Ti to their old values, going backwards from the last log record for Ti.

o Redo(Ti) sets the value of all data items updated by Ti to the new values, going forward from the first log record for Ti.

• Both operations must be idempotent:

o That is, even if the operation is executed multiple times the effect is the same as if it is executed once,Needed since operations may get re-executed during recover.

• When recovering after failure:

o Transaction Ti needs to be undone if the log contains the record <tistart>but does not contain the record<ticommit>

o Transaction Ti needs to be redone if the log contains both the record <tistart>and the record<ticommit>

• Undo operations are performed first, then redo operations.