Recovery

Chapter 19

Recovery after failure

• Different causes of failure

• The system log, commit points and checkpoints

• Caching and writing to disk

• Two techniques for recovery

– Deferred updates

• The only transactions written to disk are those that have committed

– Immediate updates

• The database may be changed before a transaction commits

Types of Failure

• The database may become unavailable for use due to

– Transaction failure: caused by:

• incorrect input, deadlock, incorrect synchronization.

– System failure: caused by:

• addressing error, application error, operating system fault, RAM failure, etc.

– Media failure: Disk head crash, power disruption, etc.

Transaction Log

• For recovery from any type of failure the log must contain these data values.

– prior to modification (BFIM - BeFore Image) and

– the new value after modification (AFIM – AFter Image)

• A sample log is given below. Back P and Next P point to the previous and next log records of the same transaction.

Caching and writing to disk

• Caching of disk pages is traditionally an operating system function

– Since when the write is done is so important, the DBMS handles it by calling the OS routines

• The DBMS keeps a directory of the buffers (disk blocks) called the DBMS cache.

• The buffer directory contains a table of <disk block address, buffer location>

– Often plus some other stuff

The DBMS cache

• It is often necessary to replace (flush) some of the cache buffers to make space for new items.

– Different strategies are used

• LRU – least recently used

• FIFO – first in first out

• Each buffer has several bits or flags associated with it

– The dirty bit – set to 0 if the buffer has not been modified since last write to disk, set to 1 if it has

– The pin-unpin bit – set to 1 if it cannot be written back to disk yet (usually waiting for a commit)

Flushing the buffers

• Two main strategies are used when a buffer is written to disk

– In-place updating

• Writes the buffer back to the same original disk location

• It overwrites the old values of any changed data items

• Recovery requires a log to undo and/or redo

– Shadowing

• Write an updated buffer to a different disk location

• Thus the old values are not overwritten

• May take a lot of disk space, but then it is not strictly necessary to keep a log of the BFIM and AFIM

Write ahead logging

• If in-place updating is used, a log is necessary for recovery

• The log must be flushed to disk before the BFIM is replaced by the AFIM in the database

• The information kept in the log depends on whether the recovery need to redo or undo, or both

– A redo needs the AFIM (after image)

– An undo needs the BFIM (before image)

Writing buffers to disk

• Terms used to specify when a buffer can be written to disk

– Steal/no-steal

• Steal is used when the DBMS cache manager steals one buffer frame to use for another transactions

– Of course, they have to be written to disk before the are overwritten

• Some buffers must not be written to disk yet because the transaction has not yet committed

• Buffers that are no-steal have the pin-unpin bit set

– Force/no-force

• If all pages updated by a transaction are immediately written to disk when the transaction commits, this is a force

Writing buffers to disk

• Typical database systems use a
steal/no-force strategy

– The advantage of steal is that less RAM has to be set aside for buffers

– The advantage of no-force is that an updated buffer may still be in RAM when anther transaction needs to update it

Checkpoints in the System Log

• Another type of entry in the log is called a checkpoint.

• Checkpoints are often used with a steal/no-force protocol.

• Taking a checkpoint involves:

– "force-writing" the contents of the db buffers to disk

– writing a checkpoint record to the log on disk. It contains

• all transactions that were in progress at the time the checkpoint was taken.

How checkpoints are used

– During a system crash, the contents of the db buffers are lost.

– If a transaction had not successfully completed, it must be undone.

– If it did complete, but had not yet been written to disk, it must be redone.

– Whether to undo or redo: an example

Main techniques for Recovery

• Deferred Update

– The database is not actually updated until after a transaction commits.

– Before commit, the updates are recorded in the transaction workspace. (buffer)

• This is impractical for large DBs with many large transactions

– During commit, the updates are first recorded to the log which is written to disk

• Only the AFIM is needed in the log

– After the log is written to disk, the buffers containing all the updates are written to the database

• If a transaction fails, there is no need for UNDO.

– the DB has not been changed

• May have to REDO, if the failure happened after the commit, before writing the update was complete.

• Known as no-undo/redo algorithm

• The redo operation is required to be idempotent

– executing it over and over is equivalent to executing it just once.

– necessary because the system may fail during recovery.

Immediate Update

• The database may be updated before the transaction reaches a commit point.

• The operations are first recorded in the log on disk before they are applied to the db.

• If a transaction fails after recording changes but before committing, the transaction must be rolled back. (operations undone)

• Two main categories

– undo/no-redo uses steal-force

• all updates are recorded on the disk before the transaction commits

– undo/redo uses steal/no-force

• The transaction is allowed to commit before all its changes are written to the db

• This leaves a committed transaction not written to disk yet.

Sample exercises

• The following log corresponds to a particular schedule at the point of a system crash for the four transactions T2, T3, AND T4.
[checkpoint]
[start_transaction, T2]
[read_item, T2, B]
[write_item, T2, B, 12]
[start_transaction, T4]
[read_item, T4, B]
[start_transaction, T3]
[write_item, T3, A, 30]
[read_item, T4, A]
[write_item, T4, A, 20]
[commit, T4]
[read_item, T2, D]
[write_item, T2, D, 25] <---- System crash

Problem:

• Suppose we use the immediate update protocol (undo/redo category) with checkpointing.

• Specify which transactions are rolled back, which operations in the log are redone, and which (if any) are undone, and

• whether any cascading rollback takes place.

• Comment on the type of scheduling used