Transcript DMS07: Concurrency Control

Chapter 8: Recovery System
Recovery and Atomicity
Log-Based Recovery
Deferred DB Modifications
Immediate DB Modifications
Checkpoints
Acknowledgements: Slides are adapted from Böhlen and
Silberschatz, Korth, and Sudarshan
J. Gamper
DMS 2006/07
1
Atomicity and Durability
Each transaction
 either completes fully
 or does not happen at all.
A DBMS only allows 2 kinds of transactions.
 Committed transactions are completed transactions with a permanent
result.
 Aborted (rolled-back) transactions have no effect on the database.
Recovery system: Ensures atomicity and durability of
transactions in the presence of failures (and concurrent
transactions).
J. Gamper
DMS 2006/07
2
Atomicity and Durability ...
Failure types
 Logical errors do not allow a transaction to continue due to some
internal condition, e.g., bad input, overflow, resource limits.
 System errors require a DBMS to terminate a transaction due to, e.g.,
a deadlock. Later re-execution is possible.
 After a system crash the content of volatile storage is lost.
 Disk failures destroy all or part of disk (stable) storage.
J. Gamper
DMS 2006/07
3
Atomicity and Durability ...
Problems of recovery procedures
 The DBMS does not know which instruction was last executed.
 Buffers may not have been written to the disk yet.
 Observable (external) writes cannot be undone, e.g., writes to the screen
or the printer. Possible solutions include:
 Delay external writes until the end of the transaction (if possible).
 Forbid external writes.
 Relax atomicity.
Recovery algorithms have two parts
1. Actions taken during normal transaction processing to ensure enough
information exists to recover from failures
2. Actions taken after a failure to recover the database contents to a state
that ensures atomicity, consistency and durability
J. Gamper
DMS 2006/07
4
Log-Based Recovery
Basic idea: In order to achieve atomicity the DBMS must first
output information describing the modifications to “stable
storage” without modifying the DB itself.
The most popular structure for recording DB modifications is the
log.
Each log record describes a significant event during transaction
processing.
J. Gamper
DMS 2006/07
5
Log-Based Recovery ...
For each DB write the DBMS creates a log record.
 < Ti, Xj, V1, V2 >
- Ti: unique transaction identifier
- Xj: unique data item identifier
- V1: old value of the data item
- V2: new value of the data item
Further log records:
 < Ti, start > if Ti has started
 < Ti, commit > if Ti has committed
 < checkpoint [T1, …, Tn] >
J. Gamper
DMS 2006/07
6
Log-Based Recovery ...
A log allows us to
 write DB modifications to the disk.
 undo DB modifications (using the old value).
 redo DB modifications (using the new value).
Properties of logs:
 Logs must be placed on stable storage.
 Logs are large because they record all DB activities.
 Checkpoints are used to reduce the size of logs. (Transactions that
committed before a checkpoint don’t have to be redone.)
J. Gamper
DMS 2006/07
7
Log-Based Recovery ...
When a failure occurs the following two operations can be
executed.
 Undo: restore DB to state prior to execution
 undo(Ti) restores the value of all data items updated by transaction Ti to the old values.
 undo must be idempotent, i.e., n applications of the operation are equivalent to 1
application.
 Redo: perform the changes to the DB over again
 redo(Ti) (re)executes all actions of transaction Ti, i.e., sets the value of all data items
updated by Ti to the new values.
 redo must be idempotent.
Two approaches using logs
 Deferred database modifications
 Immediate database modifications
J. Gamper
DMS 2006/07
8
Deferred DB Modifications
Deferred DB Modification Scheme: All DB modifications are
recorded in the log but are deferred until the transaction is
ready to commit (i.e., after partial commit).
A transaction is ready to commit if the commit log-record has
been written to stable storage, i.e., when transitioning to the
committed state.
This schema is also known as NOUNDO/REDO.
Actions after a rolled back transaction
 The log is ignored; nothing has to be undone.
J. Gamper
DMS 2006/07
9
Deferred DB Modifications ...
Actions after a crash:
 The log is consulted and each transaction that contains a (start and)
commit log record has to be redone (=> redo list).
Recovery procedure:
 To redo transactions the log has to be scanned forward.
The old value in the log record is not needed for deferred DB
updates.
Any failure that does not result in the loss of information on nonvolatile storage can be handled.
J. Gamper
DMS 2006/07
10
Immediate DB Modifications
Immediate DB Modification Scheme: DB modifications can be
written to disk before a transaction commits. However, before
doing so the modifications have to be written to the log first.
Known as UNDO/REDO.
Actions after a rolled back transaction
 The effects on the DB have to be undone.
Actions after a crash
 All transactions with a start record but without a commit record must be
undone (=> undo list).
 All transaction with a commit record must be redone (=> redo list).
J. Gamper
DMS 2006/07
11
Immediate DB Modifications ...
Recovery procedure:
 undo must be done before redo.
 for undo the log must be scanned backwards.
 for redo the log must be scanned forwards.
Any failure that does not result in the loss of information on nonvolatile storage can be handled.
J. Gamper
DMS 2006/07
12
Checkpoints
Problems in recovery procedure as discussed earlier :
 Searching the entire log is time-consuming
 We might unnecessarily redo transactions which have already output
their updates to the DB
Streamline recovery procedure by periodically performing
checkpointing
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> onto stable storage.
J. Gamper
DMS 2006/07
13
Checkpoints ...
During recovery we need to consider only the most recent
transaction Ti that started before the checkpoint, and
transactions that started after Ti.
1. Scan backwards from end of log to find the most recent <checkpoint>
record
2. Continue scanning backwards till a record <Ti start> is found.
3. Need only consider the part of log following above start record. Earlier
part of log can be ignored during recovery, and can be erased whenever
desired.
4. For all transactions (starting from Ti or later) with no <Ti commit>,
execute undo(Ti). (Done only in case of immediate modification.)
5. Scanning forward in the log, for all transactions starting from Ti or later
with a <Ti commit>, execute redo(Ti).
J. Gamper
DMS 2006/07
14
Checkpoints ...
Example:
Tf
Tc
T1
T2
T3
T4
to disk due to checkpoint)
 T1 can be ignored (updates already output
system failure
checkpoint
 T2 and T3 redone.
 T4 undone
J. Gamper
DMS 2006/07
15