Advanced Databases

Session 19
Academic year 2024-2025

Professor: Luis Angel Galindo

Failure classification
• Transaction failure
• Logical errors: transaction cannot complete due to some internal error condition
• System errors: the database system must terminate an active transaction due to
an error condition (e.g., deadlock)
• System crash: a power failure or other hardware or software failure causes the
system to crash
• Fail-stop assumption: non-volatile storage contents are assumed to not be
corrupted by system crash
• Database systems have numerous integrity checks to prevent corruption of
disk data
• Disk failure: a head crash or similar disk failure destroys all or part of disk storage
• Destruction is assumed to be detectable: disk drives use checksums to detect
failures
Storage structure
• Volatile storage
• Does not survive system crashes
• Examples: main memory, cache memory
• Non-volatile storage
• Survives system crashes
• Examples: disk, tape, flash memory, non-volatile RAM
• But may still fail, losing data
• Stable storage
• A form of storage that survives all failures
• Approximated by maintaining multiple copies on distinct non-volatile media
Stable storage
• Maintain multiple copies of each block on separate disks
• Block transfer can result in
• Successful completion
• Partial failure: destination block has incorrect information inconsistent copies!
• Total failure: destination block was never updated ⎬
• Protecting storage media from failure during data transfer
• Assuming two copies of each block, execute output operation:
1. Write the information onto the first physical block. If successfully completes
2. Write the same information onto the second physical block.
3. The output is completed only after the second write successfully completes.
• To recover from a failure, first find inconsistent blocks, then
• If either copy of an inconsistent block is detected to have an error (bad
checksum), overwrite it by the other copy. If both have no error, but
are different, overwrite the second block by the first block
 Data access

Physical blocks

Concurrent transactions share a single

disk buffer and a single log, so a buffer
block can have data items updated by one
or more transactions=> Lock mechanism!
Recovery and Atomicity
• To ensure atomicity despite failures, first output information describing the
modifications to stable storage without modifying the database itself
• Log-based recovery mechanisms
• The log is kept in stable storage
• When transaction Ti starts, it registers itself by writing a log record
<Ti start>
• Before Ti executes write(X), a log record is written
<Ti, X, V1, V2> V1 is the value of X before the write (the old value)
V2 is the value to be written to X (the new value)
• When Ti finishes it last statement, the log record <Ti commit> is written
• Two approaches using logs
• Immediate database modification allows updates of an uncommitted
transaction to be made to the buffer/disk before the transaction commits
• Deferred database modification updates to buffer/disk only at the
time of transaction commit
Inmediate DB modification. Example
Log Write Output

<T0 start>
<T0, A, 1000, 950>
<T0, B, 2000, 2050>
A = 950
B = 2050
<T0 commit>
<T1 start> BlockC output
<T1, C, 700, 600> before T1 commits
C = 600
BlockB , BlockC
<T1 commit> BlockA output
BlockA after T0 commits
Recovering from a failure
• Undo and Redo of Transactions
• 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
• Each time a data item X is restored to its old value V a special log record <Ti , X, V>
is written out
• When undo of a transaction is complete, a log record
<Ti abort> is written out.
• 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
• No logging is done in this case

• When recovering after failure:

• If the log does not contain either the record <Ti commit> or <Ti abort> => undo(Ti)
• If the log contains the record <Ti commit> or <Ti abort> => redo(Ti)
Inmediate DB modification Recovery Example

undo (T0)
B is restored to 2000 and A to 1000
log records
<T0, B, 2000>, <T0, A, 1000>, <T0, abort> are written out
Inmediate DB modification Recovery Example

redo (T0)
A and B are set to 950 and 2050
undo (T1)
C is restored to 700
Log records <T1, C, 700>, <T1, abort> are written out.
Inmediate DB modification Recovery Example

redo (T0)
A is set to 950
B is set to 2050
redo (T1)
C is set to 600
 Checkpoints
• Rationale
• Processing the entire log is time-consuming if the
system has run for a long time
• Unnecessarily redo transactions that have
already output their updates to the DB
• Periodically checkpoints as agile recovery procedure

1. Output all log records currently residing in main

memory onto stable storage.
2. Output all modified buffer blocks to the disk.
3. Write a log record < checkpoint L> onto stable
storage where L is a list of all transactions active at
the time of checkpoint.
4. All updates are stopped while doing
checkpointing
Log record buffering
• Log records are buffered in main memory, instead of being output directly to stable
storage.
• Log records are output to stable storage when a block of log records in the buffer is
full, or a log force operation is executed.
• Log force is performed to commit a transaction by forcing all its log records (including the
commit record) to stable storage.
• Several log records can thus be output using a single output operation, reducing I/O cost
• The rules below must be followed if log records are buffered:
• Log records are output to stable storage in the order in which they are created.
• Transaction Ti enters the commit state only when the log record <Ti commit> has
been output to stable storage.
• Write-Ahead-Logging (WAL) rule. Before a block of data in main memory is output to
the DB, all log records pertaining to data in that block must have been output to
stable storage.
Database buffering
• Database maintains an in-memory buffer of data blocks
• When a new block is needed, if buffer is full an existing block needs to be removed
from buffer
• If the block chosen for removal has been updated, it must be output to disk
• If a block with uncommitted updates is output to disk, log records with undo information
for the updates are output to the log on stable storage first (Write ahead logging)

• To output a block to disk

1. First acquire an exclusive latch on the block
• Ensures no update can be in progress on the block
2. Then perform a log flush
3. Then output the block to disk
4. Finally release the latch on the block
Database buffering
• Database buffer can be implemented either
• In an area of real main-memory reserved for the database, or
• In virtual memory
• Implementing buffer in reserved main-memory has drawbacks
• Memory is partitioned before-hand between database buffer and applications,
limiting flexibility
• Needs may change, and although OS knows best how memory should be divided up
at any time, it cannot change the partitioning of memory
Failure with loss of Non-volatile storage
• Periodically dump the entire content of the database to stable storage
• No transaction may be active during the dump procedure; a procedure similar to
checkpointing must take place
• Output all log records currently residing in main memory onto stable storage
• Output all buffer blocks onto the disk
• Copy the contents of the database to stable storage
• Output a record <dump> to log on stable storage

• To recover from disk failure

• restore database from most recent dump
• Consult the log and redo all transactions that committed after the dump
Remote Backup systems

• Detection of failure. Backup site must detect when primary site has failed
• Heart-beat messages
• Transfer of control
• To take over control backup site first perform recovery using its copy of the database
and all the log records it has received from the primary. Completed transactions are
redone and incomplete transactions are rolled back. After it, it becomes the new
primary
• To transfer control back to old primary when it recovers, old primary must receive
redo logs from the old backup and apply all updates locally.
Remote Backup systems
• Time to recover. To reduce delay in takeover, backup site periodically process the redo
log records, performs a checkpoint, and can then delete earlier parts of the log
• Time to commit. To ensure that the updates of a committed transaction are durable, a
transaction should not be announced committed until its log records have reached the
backup site

• Hot-Spare configuration permits very fast takeover:

• Backup continually processes redo log record as they arrive, applying the updates
locally
• When failure of the primary is detected the backup rolls back incomplete
transactions, and is ready to process new transactions
• Alternative to remote backup: DDB with replicated data
• Remote backup is faster and cheaper, but less tolerant to failure