Recovery System
Instructor : Nitesh Kumar Jha
[email protected]ITER,S’O’A(DEEMED TO BE
UNIVERSITY)
OCT 2018
Failure Classification
Transaction failure :
Logical errors: transaction cannot complete due to some
internal error condition, e.g. bad input, data not found etc.
System errors: system has entered an undesirable state(e.g.,
deadlock) for which transaction can't continue.
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 as result of a 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
Introduction to databases 1.2
Recovery Algorithms
Consider transaction Ti that transfers $50 from account A to
account B
Two updates: subtract 50 from A and add 50 to B
Transaction Ti requires updates to A and B to be output to the
database.
A failure may occur after one of these modifications have been
made but before both of them are made.
Modifying the database without ensuring that the transaction will
commit may leave the database in an inconsistent state
Not modifying the database may result in lost updates if failure
occurs just after transaction commits
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
Introduction to databases 1.3
Storage Structure
Volatile storage:
does not survive system crashes
examples: main memory, cache memory
Nonvolatile storage:
survives system crashes
examples: disk, tape, flash memory,
non-volatile (battery backed up) RAM
but may still fail, losing data
Stable storage:
a mythical form of storage that survives all failures
approximated by maintaining multiple copies on distinct
nonvolatile media
Introduction to databases 1.4
Log-Based Recovery
A log is kept on stable storage.
The log is a sequence of log records, which maintains
information about update activities on the database.
When transaction Ti starts, it registers itself by writing a
record <Ti start> to the log
Before Ti executes a write(q), a log record of the form
<Ti, Q, Vold, Vnew> is written
where Vold is the value of Q before the write, and Vnew is the
value to be written to Q.
When Ti finishes it last statement, the log record of the
form <Ti commit> is written.
When there is an abnormal termination, the log record
of the form <Ti abort> is written.
Introduction to databases 1.5
Atomicity Preservation
In the event of a failure, the system scans the log from
bottom to top in order to determine the transaction
whose atomicity/durability properties are at risk.
the recovery scheme performs following operations.
If for a transaction <Ti start> log record is found but <Ti commit>
record not found then this transaction need to be rolled back
To preserve atomicity, undo(Ti) is executed.
Undo(Ti): restores all modified data items to their old values as
depicted in the corresponding modification log records of
transaction Ti
Introduction to databases 1.6
Durability Preservation
All the transactions who have completed execution
and subsequently committed by the time failure occurs
have their durability property at risk.
Procedure
The logs are scanned backward to find the transactions having
both <Ti start> and <Ti commit> records are present in the log
To preserve durability execute Redo(Ti)
It sets the value of each modified data item of transaction Ti to
its new value as found in all modified log records of transaction
Ti.
Both Undo(Ti), and Redo(Ti) operation are idempotent, i.e.
undoing or redoing a transaction several times ensures the
same final outcome.
Introduction to databases 1.7
Preservation example
T1: <T1 start> <T2 commit>
Read (A) <T3 start>
<T1, A, 1000,950 > T3:
A=A-50 Read (D)
Write(A) Read(E)
Read(B) Display(D+E) F3
<T1, B, 500,550 > <T3 commit>
F1:
B=B+50
F1 Undo(T1)
Write(B)
F2:
<T1commit>
Undo(T2)
T2: <T2 start>
Recovery
Redo(T1)
Read (C) Procedure
F3:
<T2, C, 300,400 > Undo (T3)
C=C+100 Redo(T2)
F2
Write(C) Redo(T1)
Introduction to databases 1.8
Approaches to log based recovery
Immediate database modification: allows updates of
an uncommitted transaction to be made to the
buffer, or the disk itself, before the transaction commits
In this scheme, transaction needs to undergo Undo(Ti)
operation in case of failure to preserve atomicity.
Deferred database modification: performs updates to
buffer/disk only at the time of transaction commit
In this scheme, transaction does not need to perform Undo(Ti)
operation in the event of failure.
The recovery procedure in this case needs to ignore and
delete corresponding modification log record of the failed
transaction.
Introduction to databases 1.9
Database Modification Example
Not IMP
Log Write Output
<T0 start>
<T0, A, 1000, 950>
<To, B, 2000, 2050>
A = 950
B = 2050
<T0 commit>
<T1 start>
<T1, C, 700, 600> BC output before
C = 600 T1 commits
BB , BC
<T1 commit>
BA
BA output after
Note: BX denotes block containing X. T0 commits
Introduction to databases 1.10
Data Access with Concurrent transactions
Not IMP
buffer
Buffer Block A input(A)
X A
Buffer Block B Y B
output(B)
read(X)
write(Y)
x2
x1
y1
work area work area
of T1 of T2
memory disk
Introduction to databases 1.11
Checkpoints Not IMP
Redoing/undoing all transactions recorded in the log can be
very slow
Processing the entire log is time-consuming if the system has
run for a long time
unnecessary redo of transactions which have already output
their updates to the database.
To get rid of above overheads, checkpoints are introduced and
checkpointing is performed periodically.
All updates are stopped while doing 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 L> onto stable storage where
L is a list of all transactions active at the time of checkpoint.
Introduction to databases 1.12
Checkpoints (Cont.) Not IMP
During recovery we need to consider only the most recent
transaction Ti that started before the checkpoint, and
transactions that started after Ti.
Scan backwards from end of log to find the most recent
<checkpoint L> record
Only transactions that are in L or started after the checkpoint
need to be redone or undone
Transactions that committed or aborted before the
checkpoint already have all their updates output to stable
storage.
Some earlier part of the log may be needed for undo operations
Continue scanning backwards till a record <Ti start> is found
for every transaction Ti in L.
Parts of log prior to earliest <Ti start> record above are not
needed for recovery, and can be erased whenever desired.
Introduction to databases 1.13
Example of Checkpoints Not IMP
Tc Tf
T1
T2
T3
T4
checkpoint system failure
T1 can be ignored (updates already output to disk due to
checkpoint)
T2 and T3 redone.
T4 undone
Introduction to databases 1.14
Checkpoints (contd) Not IMP
With the use of checkpoints, the recovery procedure
become efficient and straight line
When failure occurs, the log only needs to be
scanned up to the latest checkpoint.
During this scan, those transactions whose commit
record are found (<Ti commit>) are determined to
be redone.
Transactions without any commit record found
during this scan are undone.
Introduction to databases 1.15
End of Chapter 16
