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