The principal technique for supporting resilience is a log, which record securely the history of database changes. There’re three different styles of logging: “undo” , “redo” and ”undo/redo”.

Undo-Logging—makes repairs to the database state by undoing the effects of transactions that may not have completed before the crash.

The Undo-Logging Rules:

U1: If transaction T modifies database element X, then the log record of the form <T,X,v>must be written to disk before the new value of X is written to disk.

U2: If a transaction commits，then its COMMIT log record must be written to disk only after all database elements changed by the transaction have been written to disk, but as soon thereafter as possible.

Redo-Logging—the requirement for immediate backup of database elements to disk can be avoided if we use a logging mechanism called redo logging.

The Redo-Logging Rules:

R1: Before modifying any database element X on disk, it is necessary that all log records pertaining to this modification of X, including both the update record<T,X,v>and the <COMMIT T>record, must appear on disk.

Undo/redo logging—provides increased flexibility to order actions, at the expense of maintaining more information on the log.

The Undo/Redo Rules:

UR1:Before modifying any database element X on disk because of changes made by some transaction T, it is necessary that the update record<T,X,v,w> appear on disk.

The principal differences between redo and undo logging are:

1. While undo logging cancels the effect of incomplete transactions and ignores committed ones during recovery, redo logging ignores incomplete transactions and repeats the changes made by committed transactions.
2. While undo logging requires us to write changed database elements to disk before the COMMIT log record reaches disk, redo logging requires that the COMMIT record appear on disk before any changed values reach disk.
3. While the values of changed database elements are exactly what we need to recover when the undo rules U1 and U2are followed, to recover using redo logging, we need the new values instead.

The drawbacks of undo and redo logging are：

Undo logging requires that data be written to disk immediately after a transaction finished, perhaps increasing the number of disk I/O’s that need to be performed.

On the other hand, redo logging requires us to keep all modified blocks in buffers until the transaction commits and the log records have been flushed, perhaps increasing the average number of buffers required by transactions.

Both undo and redo logs may put contradictory requirements on how buffers are handled during a checkpoint, unless the database elements are complete blocks or sets of blocks. For instance, if a buffer contains one another database element A that was changed by a committed transaction and another database element B that was changed in the same buffer by a transaction that has not yet had its COMMIT record written to disk, then we are required to copy the buffer to disk because of A but also forbidden to do so, because rule R1 applies to B.