Outline

Failure Classification
Storage Structure
Recovery and Atomicity
Log-Based Recovery
Recovery Algorithm
Chapter 16: Recovery System

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use

Database System Concepts - 6th Edition 16.2 ©Silberschatz, Korth and Sudarshan

Failure Classification Recovery Algorithms

Transaction failure : Consider transaction Ti that transfers $50 from account A to account B
Logical errors: transaction cannot complete due to some internal Two updates: subtract 50 from A and add 50 to B
error condition Transaction Ti requires updates to A and B to be output to the
System errors: the database system must terminate an active database.
transaction due to an error condition (e.g., deadlock) A failure may occur after one of these modifications have been
System crash: a power failure or other hardware or software failure made but before both of them are made.
causes the system to crash. Modifying the database without ensuring that the transaction will
Fail-stop assumption: non-volatile storage contents are assumed commit may leave the database in an inconsistent state
to not be corrupted as result of a system crash Not modifying the database may result in lost updates if failure
4 Database systems have numerous integrity checks to prevent occurs just after transaction commits (buffer)
corruption of disk data Recovery algorithms have two parts
Disk failure: a head crash or similar disk failure destroys all or part of 1. Actions taken during normal transaction processing to ensure
disk storage enough information exists to recover from failures
Destruction is assumed to be detectable: disk drives use 2. Actions taken after a failure to recover the database contents to a
checksums to detect failures state that ensures atomicity, consistency and durability

Database System Concepts - 6th Edition 16.3 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.4 ©Silberschatz, Korth and Sudarshan
 Storage Structure Data Access

Volatile storage: Physical blocks are those blocks residing on the disk.
does not survive system crashes System buffer blocks are the blocks residing temporarily in main
memory.
examples: main memory, cache memory
Block movements between disk and main memory are initiated
Nonvolatile storage: through the following two operations:
survives system crashes input(B) transfers the physical block B to main memory.
examples: disk, tape, flash memory, output(B) transfers the buffer block B to the disk, and replaces
non-volatile (battery backed up) RAM the appropriate physical block there.
but may still fail, losing data We assume, for simplicity, that each data item fits in, and is stored
Stable storage: inside, a single block.
a mythical form of storage that survives all failures
approximated by maintaining multiple copies on distinct
nonvolatile media

Database System Concepts - 6th Edition 16.5 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.8 ©Silberschatz, Korth and Sudarshan

Data Access (Cont.) Example of Data Access

Each transaction Ti has its private work-area in which local copies of buffer
all data items accessed and updated by it are kept. Buffer Block A input(A)
X A
Ti's local copy of a data item X is denoted by xi.
Buffer Block B Y B
BX denotes block containing X output(B)
Transferring data items between system buffer blocks and its private
work-area done by: read(X)
read(X) assigns the value of data item X to the local variable xi. write(X)
write(X) assigns the value of local variable xi to data item {X} in
the buffer block.
x1
Transactions
y1
Must perform read(X) before accessing X for the first time
(subsequent reads can be from local copy) work area of T1
The write(X) can be executed at any time before the transaction
commits
Note that output(BX) need not immediately follow write(X). System memory disk
can perform the output operation when it deems fit.

Database System Concepts - 6th Edition 16.9 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.10 ©Silberschatz, Korth and Sudarshan
 Recovery and Atomicity Log-Based Recovery
To ensure atomicity despite failures, we first output A log is kept on stable storage.
information describing the modifications to stable storage The log is a sequence of log records, which maintains
without modifying the database itself. information about update activities on the database.
We study log-based recovery mechanisms in detail When transaction Ti starts, it registers itself by writing a record
<Ti start>
We first present key concepts
to the log
And then (module 17) present the actual recovery
algorithm Before Ti executes write(X), a log record
<Ti, X, V1, V2>
Less used alternative: shadow-paging (brief details is written, where V1 is the value of X before the write (the old value),
presented in the book). and V2 is the value to be written to X (the new value).
In this Module we assume serial execution of transactions. When Ti finishes it last statement, the log record <Ti commit> is
In Module 17, we consider the case of concurrent written.
transaction execution. Two approaches using logs:
Immediate database modification
Deferred database modification

Database System Concepts - 6th Edition 16.11 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.12 ©Silberschatz, Korth and Sudarshan

Database Modification Transaction Commit

The immediate-modification scheme allows updates of an A transaction is said to have committed when its commit log
uncommitted transaction to be made to the buffer, or the disk itself, record is output to stable storage
before the transaction commits
All previous log records of the transaction must have been
Update log record must be written before a database item is written
output already
We assume that the log record is output directly to stable storage
Writes performed by a transaction may still be in the buffer when
(Will see later that how to postpone log record output to some the transaction commits, and may be output later
extent)
Output of updated blocks to disk storage can take place at any time
before or after transaction commit
Order in which blocks are output can be different from the order in
which they are written.
The deferred-modification scheme performs updates to buffer/disk
only at the time of transaction commit
Simplifies some aspects of recovery
But has overhead of storing local copy
We cover here only the immediate-modification scheme

Database System Concepts - 6th Edition 16.13 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.14 ©Silberschatz, Korth and Sudarshan
 Immediate Database Modification Example Undo and Redo Operations
Log Write Output Undo of a log record <Ti, X, V1, V2> writes the old value V1 to X
Redo of a log record <Ti, X, V1, V2> writes the new value V2 to X
<T0 start>
Undo and Redo of Transactions
<T0, A, 1000, 950>
undo(Ti) restores the value of all data items updated by Ti to
<To, B, 2000, 2050>
their old values, going backwards from the last log record for Ti
A = 950
B = 2050 4 Each time a data item X is restored to its old value V, a
special log record (called redo-only) <Ti , X, V> is written out
<T0 commit>
4 When undo of a transaction is complete, a log record
<T1 start>
<T1, C, 700, 600> <Ti abort> is written out (to indicate that the undo was
BC output before T1 completed)
C = 600 commits
BB , BC redo(Ti) sets the value of all data items updated by Ti to the new
<T1 commit> values, going forward from the first log record for Ti
BA 4 No logging is done in this case
BA output after T0
Note: BX denotes block containing X. commits

Database System Concepts - 6th Edition 16.15 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.16 ©Silberschatz, Korth and Sudarshan

Undo and Redo Operations (Cont.) Undo and Redo on Recovering from Failure

The undo and redo operations are used in several When recovering after failure:
different circumstances: Transaction Ti needs to be undone if the log
The undo is used for transaction rollback during 4 contains the record <Ti start>,
normal operation (in case a transaction cannot 4 but does not contain either the record <Ti commit>
complete its execution due to some logical error).
Transaction Ti needs to be redone if the log
The undo and redo operations are used during
recovery from failure. 4 contains the records <Ti start>
We need to deal with the case where during recovery 4 and contains the record <Ti commit>
from failure another failure occurs prior to the system
having fully recovered.

Database System Concepts - 6th Edition 16.17 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.19 ©Silberschatz, Korth and Sudarshan
 Immediate Modification Recovery Example Checkpoints
Redoing/undoing all transactions recorded in the log can be very slow
Below we show the log as it appears at three instances of time.
Processing the entire log is time-consuming if the system has run for
a long time
We might unnecessarily redo transactions which have already output
their updates to the database.
Streamline recovery procedure by periodically performing checkpointing
All updates are stopped while doing checkpointing
1. Output all log records currently residing in main memory onto stable
storage.
Recovery actions in each case above are: 2. Output all modified buffer blocks to the disk.
(a) undo (T0): B is restored to 2000 and A to 1000, and log records
3. Write a log record < checkpoint L> onto stable storage where L is a
<T0, B, 2000>, <T0, A, 1000>, <T0, abort> are written out
list of all transactions active at the time of checkpoint.
(b) redo (T0) and undo (T1): A and B are set to 950 and 2050 and C is
restored to 700. Log records <T1, C, 700>, <T1, abort> are written out.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050
respectively. Then C is set to 600

Database System Concepts - 6th Edition 16.20 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.21 ©Silberschatz, Korth and Sudarshan

Checkpoints (Cont.) Example of Checkpoints

During recovery we need to consider only the most recent transaction
Tc Tf
Ti that started before the checkpoint, and transactions that started
after Ti. T1
Scan backwards from end of log to find the most recent T2
<checkpoint L> record
T3
Only transactions that are in L or started after the checkpoint
need to be redone or undone T4
Transactions that committed or aborted before the checkpoint
already have all their updates output to stable storage.
checkpoint system failure
Some earlier part of the log may be needed for undo operations
Continue scanning backwards till a record <Ti start> is found for T1 can be ignored (updates already output to disk due to checkpoint)
every transaction Ti in L. T2 and T3 redone.
Parts of log prior to earliest <Ti start> record above are not T4 undone
needed for recovery, and can be erased whenever desired.

Database System Concepts - 6th Edition 16.22 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.23 ©Silberschatz, Korth and Sudarshan
 Recovery Schemes Concurrency Control and Recovery
With concurrent transactions, all transactions share a single disk
So far: buffer and a single log
We covered key concepts A buffer block can have data items updated by one or more
We assumed serial execution of transactions transactions

Now: We assume that if a transaction Ti has modified an item, no other

transaction can modify the same item until Ti has committed or
We discuss concurrency control issues aborted
We present the components of the basic recovery algorithm i.e. the updates of uncommitted transactions should not be visible
to other transactions
4 Otherwise how do we perform undo if T1 updates A, then T2
updates A and commits, and finally T1 has to abort?
Can be ensured by obtaining exclusive locks on updated items
and holding the locks till end of transaction (strict two-phase
locking)
Log records of different transactions may be interspersed in the log.

Database System Concepts - 6th Edition 16.25 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.26 ©Silberschatz, Korth and Sudarshan

Example of Data Access with Concurrent transactions Recovery Algorithm

buffer Logging (during normal operation):
Buffer Block A input(A)
X A <Ti start> at transaction start
Buffer Block B Y B <Ti, Xj, V1, V2> for each update, and
output(B) <Ti commit> at transaction end
read(X) Transaction rollback (during normal operation)
write(Y) Let Ti be the transaction to be rolled back
Scan log backwards from the end, and for each log record of Ti of
x2 the form <Ti, Xj, V1, V2>
x1 4 perform the undo by writing V1 to Xj,
y1 4 write a log record <Ti , Xj, V1>

work area work area – such log records are called compensation log records
of T1 of T2 Once the record <Ti start> is found stop the scan and write the log
record <Ti abort>
memory disk

Database System Concepts - 6th Edition 16.27 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.28 ©Silberschatz, Korth and Sudarshan
 Recovery Algorithm Recovery Algorithm
Create undi-list and redo-list: Recovery:
1. Initial undo-list = Æ and redo-list = Æ 1. Scan log backwards from end until <Ti, start> has been found for
2. Scan log file backward from the end to the last <checkpoint L> every transaction in undo-list: undo(Ti)

1. Whenever a <Ti, commit> is found: 2. Find last <checkpoint L> record: scan forward the log file and
⇒ add Ti into the redo-list preform undo(Ti) for every Ti in redo-list

2. Whenever a <Ti, start> is found and Ti Ï redo-list

⇒ addTi into the undo-list
3. "Ti Î L but Ti Ï redo-list or undo-list:
⇒ addTi into the undo-list

Database System Concepts - 6th Edition 16.31 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.32 ©Silberschatz, Korth and Sudarshan

Example of Recovery Exercise

Given the following log file:

a. Identify L1, L2. <T1, start>
b. Identify value of A – E on the DB after the <T2, start>
crash and before the recovery
<T1, A, 10, 30>
c. Identify value of A – E on the DB after the
recovery. <T1, B, 15, 35>
<T2, C, 110, 160>
Solution: <checkpoint L1>
a. L1 = {T1, T2}, L2 = {T2, T3}
<T1, commit>
b. A=30, B=35, C=160, <T2, D, 210, 260>
D=260, E=1510 <T3, start>
c. A=30, B=35, C=160, <T3, E, 1010, 1510>
D=260, E=1010(*) <checkpoint L2>
<T2, commit>
~~~ crash ~~~

Database System Concepts - 6th Edition 16.33 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 16.34 ©Silberschatz, Korth and Sudarshan
 End of Chapter 16

Database System Concepts - 6th Edition 16.82 ©Silberschatz, Korth and Sudarshan