CRASH RECOVERY

Er. साहित बराल

07/11/2022
9.1 Failure Classification
Recovery System:
◦DBMS is highly complex system with hundreds of transactions being executed
every second.
◦Availability of DBMS depends on its complex architecture and underlying h/w
or system s/w.
◦If it fails or crashes amid transactions being executed, it is expected that the
system would follow some sort of algorithms or techniques to recover from
crashes or failures.
◦There may be several causes of failure including power failure, disk crashed,
s/w bugs etc.
9.1 Failure Classification
Recovery System:
Different types of failures are
• Transaction failure
• System crash
• Disk failure
Database Recovery
Failure Classification
Transaction failure
• Logical errors − Where a transaction cannot complete because it has some
code error or any internal error condition.
• System errors − Where the database system itself terminates an active
transaction because the DBMS is not able to execute it, or it has to stop
because of some system condition.
For example, in case of deadlock or resource unavailability, the system
aborts an active transaction.
Database Recovery
Failure Classification
System Crash
◦ There are problems
− External to the system, that may cause the system to stop abruptly and
cause the system to crash.
◦ For example, interruptions in power supply may cause the failure of underlying
hardware or software failure.
◦ Examples may include operating system errors.
Database Recovery
Failure Classification
Disk Failure
◦ In early days of technology evolution, it was a common problem where hard-
disk drives or storage drives used to fail frequently.
◦ Disk failures include formation of bad sectors, unreachability to the disk, disk
head crash or any other failure, which destroys all or a part of disk storage.
9.2 Concept of log-based recovery and shadow paging
◦Recovery algorithms are techniques to ensure database consistency and
transaction atomicity and durability despite failures.
◦Recovery algorithms have two parts:
◦Actions taken during normal transaction processing to ensure enough
information exists to recover from failure.
◦Actions taken after a failure to recover the database contents to a state that
ensures atomicity, consistency and durability.
◦Modifying the database without ensuring that the transaction will commit may
leave the database in an inconsistent state.
◦To ensure atomicity despite failures, we first o/p information describing the
modification to stable storage without modifying database itself
9.2 Concept of log based recovery and shadow paging
Two approaches:
• Log Based Recovery
• Shadow Paging
Database Recovery
Log-Based Recovery
• Logs are the sequence of records, that maintain the records of actions
performed by a transaction.
• In Log – Based Recovery, log of each transaction is maintained in some
stable storage. If any failure occurs, it can be recovered from there to recover
the database.
• The log contains the information about the transaction being executed, values
that have been modified and transaction state.
• All these information will be stored in the order of execution.
Database Recovery
Example:
Assume, a transaction to modify the address of an employee. The following
logs are written for this transaction,

Log 1: Transaction is initiated, writes 'START' log.

Log: <Tn START>

Log 2: Transaction modifies the address from 'Pune' to 'Mumbai'.

Log: <Tn Address, 'Pune', 'Mumbai'>

Log 3: Transaction is completed. The log indicates the end of the transaction.
Log: <Tn COMMIT>
Database Recovery
Two approaches using logs
◦Deferred database modification
◦Immediate database modification
Database Recovery
Deferred database modification
◦ It ensures transaction atomicity by recording all database modification in the
log but deferring the execution of all write operations of a transaction until the
transaction partially commits.
◦ When a transaction partially commits the information on the log associated
with the transaction is used in executing the deferred writes.
◦ If the system crashes before the transaction completes its execution, then the
information on the log is simply ignored.
◦ Transaction starts by writing <Ti , start> record to log.
◦ A write(X) operation results in a log record <Ti, X, V> being written where V is
the new value of X. here old value is not needed.
Database Recovery
Deferred database modification
• Deferred Update Steps:
• ‘write’ operation is not performed on X at this time but is deferred.
• When Ti partially commits <Ti , commit> is written to log.
• Finally, the log records are read and used to actually execute the
previously deferred writes.
• Redo only scheme:
• During recovery after crash, a transaction needs to be redone if and only if
both <Ti, start> and <Ti , commit> are there in log.
• Redoing a transactionTi (redo(Ti)) sets the value of all data items
updated by the transaction to the new values.
• Crashes can occur while the transaction is executing the original updates or
while recovery action is being taken.
Deferred database modification
◦E.g. Transaction T0 and T1 such that T0 executes before T1.

T0 : read(A) T1 : read(C) LOG D

A = A - 50 C = C - 100 <T0, start> B
write(A) write(C) <T0, A, 950>
read(B) <T0, B, 2050>
<T0,
B=B+50 commit> A = 950
write(B) B=
<T1, start> 2050
<T1, C, 900>
<T1, commit>
C=
900
Deferred database modification
◦ Recovery procedure redo(Ti) sets the value of all data items updated by
transaction Ti to new values.
◦ Below is the log as it appears at three instances of time.
<T0, start> <T0, start> <T0, start>
<T0, A, 950> <T0, A, 950> <T0, A, 950>
<T0, B, 2050> <T0, B, 2050> <T0, B, 2050>
<T0, commit> <T0, commit>
<T1, start> <T1, start>
<T1, C, 900>
<T1, C, 900>
<T1, commit>

Fig: Fig: Fig:

a b c
Deferred database modification
• If log on stable storage at time of crash is as in fig. a, No redo action
need to be taken
• If log on stable storage at time of crash is as in fig. b, redo (T0) must be
performed since <T0, commit> is present.
• If log on stable storage at time of crash is as in fig. c, {redo(T0),
redo(T1)} both must be performed since <T0, commit> and <T1,
commit> are present.
Immediate database modification
• Allows database updates of an uncommitted transaction to be made as
the writes are issued.
• Since, undoing may be needed, update logs must have both old value
and new value.
• Update log record must be written before database item is written
Immediate database modification
• E.g. Transaction T0 and T1 such that T0 executes before T1.

T0 : read(A) T1 : read(C) LOG DB

A = A - 50 C = C - 100 <T0, start>
write(A) write(C) <T0, A, 1000, 950>
read(B) <T0, B, 2000, 2050>
A = 950
B=B+50 B = 2050
write(B) <T0, commit>
<T1, start>
<T1, C, 1000, 900>
C = 900
<T1, commit>
Immediate database modification
• Here, recovery procedure has two operations instead of one.
• Undo(Ti) : restores the value of all data items updated by Ti to their
old values going backwards from last log record for Ti.
• 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 .
• When recovering after failure transaction Ti needs to be redone if the
log contains both the record <Ti, start> and record <Ti , commit>
• Undo operations are performed first then only Redo operation.
Immediate database modification
• Below is the log as it appears at three instances of time.

<T0, start> <T0, start> <T0, start>

<T0, A, 1000, 950> <T0, A, 1000, 950> <T0, A, 1000, 950>
<T0, B, 2000, 2050> <T0, B, 2000, 2050> <T0, B, 2000, 2050>
<T0, commit> <T0, commit>
<T1, start> <T1, start>
<T1, C, 1000, 900> <T1, C, 1000, 900>
<T1, commit>

Fig: a Fig: b Fig: c

Immediate database modification
• If log on stable storage at time of crash is as in fig. a, Undo(T0) must be
performed.
• If log on stable storage at time of crash is as in fig. b, Undo(T1) and
then Redo(T0) must be performed.
• If log on stable storage at time of crash is as in fig. c, Redo(T0) and
Redo(T1) must be performed.
Database Recovery
Checkpoint
◦Checkpoint acts like a benchmark.
◦Checkpoints are also called as Syncpoints or Savepoints.
◦The DBMS checkpoint is a procedure of compressing the transaction
log file by transferring the old transaction to permanent storage.
◦It helps in system recovery when the failure occurs.
◦The procedure of system recovery includes reading of log file in reverse
order and maintaining redo and undo lists.
Database Recovery
Checkpoint
Recovery using Checkpoint
The schematic representation of the system recovery when the failure occurs
during the execution of concurrent transactions.
Database Recovery
Checkpoint
Transactions and their operations in the above diagram:

T1 T2 T3 T4
Commit
START
COMMIT
START
COMMIT
START
FAILURE
Database Recovery
Checkpoint
Table of transactions operations and the lists they are placed in

Operations List

<Tn,start> and <Tn,commit> Redo list

<Tn,commit> Redo list

<Tn,start> Undo list

Checkpoint
Following are the steps to be performed for the system recovery using
checkpoint.
◦ The transaction log file are read in the reverse order, ie., from T4 to T1.
◦ Redo and Undo are the lists that are created and maintained by the system.
◦ If the transactions contain operations like <Tn, start> and <Tn, commit> together
or <Tn, commit> alone then the transaction will be stored in the redo list. In the above
diagram, The transaction T1 contains only <Tn, commit> and transactions T2 and T3
contain <Tn, start> and <Tn, commit> both the operations and therefore transactions
T1, T2 and T3 are stored in the redo list.
◦ If the transactions contain operations like <Tn, start> but not <Tn, commit>, then the
transaction will be stored in undo list. In the above diagram, The transaction T4
contains <Tn, start> but not <Tn, commit> operation, and therefore transaction T4 is
stored in undo list.
9.2 Concept of log based recovery and shadow paging
• Shadow Paging :
• Shadow Paging is a recovery technique that provides atomicity and durability
in database system
• Shadow paging is one of the techniques that is used to recover from failure.
We all know that recovery means to get back the information, which is lost. It
helps to maintain database consistency in case of failure.
• It provides a way to implement failure recovery without requiring a log, which
is typical in traditional approaches.
9.2 Concept of log based recovery and shadow paging
• Shadow Paging :
Now let see the concept of shadow paging step by step −
• Step 1 − Page is a segment of memory. Page table is an index of pages. Each
table entry points to a page on the disk.
• Step 2 − Two page tables are used during the life of a transaction: the current
page table and the shadow page table. Shadow page table is a copy of the current
page table.
• Step 3 − When a transaction starts, both the tables look identical, the current table
is updated for each write operation.
• Step 4 − The shadow page is never changed during the life of the transaction.
• Step 5 − When the current transaction is committed, the shadow page entry
becomes a copy of the current page table entry and the disk block with the old
data is released.
• Step 6 − The shadow page table is stored in non-volatile memory. If the system
crash occurs, then the shadow page table is copied to the current page table.
9.2 Concept of log based recovery and shadow paging
• Shadow Paging :
• Disadvantages of shadow paging
• Copying the entire page table is very expensive
• Can be reduced by using a page table structured like B+ tree. here, no need
to copy entire tree, only need to copy paths in the tree that lead to update
leaf nodes.
• Data gets fragmented (related pages get separated on disk)
• After every transaction completion old version of modified data need to be
garbage collected.
9.2 Concept of log based recovery and shadow paging
• Shadow Paging :

Disk
Shadow Page Current
Page 1 (Original) Page
1 1
4
2 2
3 (modified)
3 3
2
4 4
5
5 5
1 (modified)
3 (Original)
3. Data Backup/Recovery
• Is to protect data.
• Backup files can protect against accidental loss of data, database
corruption and other failures.
• Backup tapes are stored in secured location.
• With backup and recovery plan, we can easily recover our important data
from any type of disasters.
3. Data Backup/Recovery
• To create backup plan, deal with following
• How important is data on your system?
• What type of information does the data contain?
• How often does the data change?
• How quickly do you need to recover the data?
• Do you have equipment to perform backup?
• Who will be responsible for backup and recovery plan?
• What is best time to schedule backup?
3. Data Backup/Recovery • Common backup solutions
• Backup plan depends on factors like • Tape drive
• Capacity • Digital audio tape (DAT) drives
• Reliability • Disk drives
• Extensibility • Magnetic optical drive
• Speed • Auto loader tape systems
• Cost • Removable disks
Remote Backup / Online Backup
• Here files, folders or entire contents of hard drive are regularly backed up
on a remote server with n/w connection.
• Here risk of catastrophic data loss as a result of fire, theft, file corruption
or other disaster is eliminated.
• Encryption and password protection system helps to ensure privacy and
security.
• For large organization and for practically valuable data, online backup
strategy is wise investment.
• In database, it is backup performed on data even though it is actively
accessible to users and may currently be in state of being updated.
• Cloud computing, remote login method are for remote backup and
recovery.
9.4 Remote Backup System
• Remote Backup / Online Backup
• Remote Backup / Online Backup
• Catastrophic failure is one where stable , secondary storage device get corrupted.
To recover from catastrophic failure
• Remote backup
• Backup taken to magnetic tapes and stored in safer place.

Remot
Local e
Database Server