Chapter - 5

Crash Recovery and Backup

Recovery System :

A computer system, like any other device, is subject to

failure from a variety of causes : disk crash, power
outage, software error, a fire in the machine room,
even sabotage.

In any failure, information may be lost.

Recovery System : A ICD

Therefore, the database system must take actions in

advance to ensure that the atomicity and durability
properties of transactions
Recovery System : A ICD

The recovery scheme must also support high

availability, that is, the database should be usable for
a very high percentage of time.
Recovery System : A ICD

To support high availability in the face of machine

failure (as also planned machine shutdowns for
hardware/software upgrades and maintenance), the
recovery scheme must support the ability to keep a
backup copy of the database synchronized with the
current contents of the primary copy of the database.
Recovery System : A ICD

If the machine with the primary copy fails, transaction

processing can continue on the backup copy.
Failure Classification - Recovery System (ACID) :
1] Transaction Failure :
There are two types of errors that may cause a transaction to fail:
° Logical error : The transaction can no longer continue with its
normal execution because of some internal condition, such as bad
input, data not found, overflow, or resource limit exceeded.
° System error : The system has entered an undesirable state (e.g.,
deadlock), as a result of which a transaction cannot continue with
its normal execution. The transaction, however, can be reexecuted at

a later time.
Failure Classification - Recovery System (ACID) :

2] System Crash : There is a hardware malfunction,

or a bug in the database software or the operating system,
that causes the loss of the content of volatile storage and
brings transaction processing to a halt. The content of
non-volatile storage remains intact and is not corrupted.
Failure Classification - Recovery System (ACID) :

2] System Crash : The assumption that hardware

errors and bugs in the software bring the system to a halt,
but do not corrupt the non-volatile storage contents, is
known as the fail-stop assumption. Well-designed systems
have numerous internal checks, at the hardware and the
software level, that bring the system to a halt when there
is an error. Hence, the fail-stop assumption is a reasonable
one.
Failure Classification - Recovery System (ACID) :

3] Disk Failure : A disk block loses its content as a

result of either a head crash or failure during a data-
transfer operation. Copies of the data on other disks, or
archival backups on tertiary media, such as DVD or tapes,
are used to recover from the failure.
Recovery System (ACID) :

 To determine how the system should recover from

failures, we need to identify the failure modes of those
devices used for storing data.

 Next, we must consider how these failure modes

affect the contents of the database.
Recovery System (ACID) :

We can then propose algorithms to ensure database consistency and

transaction atomicity despite failures. These algorithms, known as
recovery algorithms, have two parts:

1. Actions taken during normal transaction processing to ensure

that enough information exists to allow recovery from failures.

2. Actions taken after a failure to recover the database contents

to a state that ensures database consistency, transaction
atomicity, and durability.
Recovery and Atomicity
 Recovery and Atomicity
• To ensure atomicity despite failures, we first output
information describing the modifications to stable
storage without modifying the database itself.
• We study two approaches:
1] Log-Based Recovery
2] Shadow-Paging
• We assume (initially) that transactions run serially, that
is, one after the other.
Log-Based Recovery
 Log-Based Recovery
• A log is kept on stable storage.

– The log is a sequence of log records, and

maintains a record of update activities on the
database.
<Ti start> Transaction Ti has started.
<Ti commit> Transaction Ti has committed.
<Ti abort> Transaction Ti has aborted.
 Log-Based Recovery
Two approaches using logs

– Deferred Database Modification

– Immediate Database Modification

 Deferred Database Modification
• The deferred database modification scheme records
all modifications to the log, but defers all the writes to
after partial commit.

• Assume that transactions execute serially

 Deferred Database Modification
• 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 for X

– Note: old value is not needed for this scheme

• The write is not performed on X at this time, but is

deferred.

• When Ti partially commits, <Ti commit> is written to

the log
 Deferred Database Modification

• Finally, the log records are read and used to actually

execute the previously deferred writes.
Deferred Database Modification (Cont.)
• During recovery after a crash, a transaction needs to be redone if and only if
both <Ti start> and<Ti commit> are there in the log.
• Redoing a transaction Ti ( redoTi) 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
• example transactions T0 and T1 (T0 executes before T1):

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

A: - A - 50 C:- C- 100
Write (A) write (C)
read (B)
B:- B + 50
write (B)
Data Access Main operations :

1] read
2] write

Data Recovery actions :

1] undo – old value of database

2] redo - New value of database
 A= 1000 B=2000 C=700

To : T1 :
read(A); read(C);
A:=A-50; C:=C-100;
write(A); write(C);
read(B);
B:=B+50;
write(B);
 Old Value A= 1000 B=2000 C=700
Log of To & T1 :
To :
<T0 start> REDO
read(A);
<T0 , A,950>
A:=A-50;
<T0,B,2050>
write(A);
<T0,COMMIT>
read(B);
<T1, START>
B:=B+50;
<T1,C,600> ?
write(B);
<T1,COMMIT>
T1 :
read(C); After a failure , transactions Ti need to
C:=C-100; be redone (REDO) if and only if log
write(C); contain <T0 start>
<T0,COMMIT>
 A=1000, B=2000 C=700

<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>
Fig A
<T1,C,600> <T1,C,600>
<T1,COMMIT>
Fig B
Fig C

redo action on T1
No redo action No redo action on T1 redo action on T0
Because no commit Redo action on T0
A=950, B=2050
A=1000, B=2000
A=950, B=2050
values as it is. C=600

C=700
Immediate Database Modifications
Immediate Database Modifications :

This technique allows database modification to be

output to the database while transaction is still in the
active state. Data modifications written by active
transactions are called uncommitted modifications.

Undo – restores old values

Redo - restores new values

 A=1000, B=2000 C=700

<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>
Fig A
<T1,C,700,600> <T1,C,700,600>
<T1,COMMIT>
Fig B
Fig C
Redo action on T1
undo action
Undo action on T1 Redo action on T0
A=1000, B=2000 Redo action on T0
A=950, B=2050
values as it is.
A=950, B=2050
C=600
C=700
Checkpoint
Checkpoint :

To check which transaction redo or undo then that is

time consuming then using checkpoint to reduce time.
Many time we need redo but actually we already write
new values in DB.

Add <checkpoint >

 Checkpoints
• Problems in recovery procedure as discussed earlier :

1. Searching the entire log is time-consuming.

2. We might unnecessarily redo transactions which have

already.

3. Output their updates to the database.

 Checkpoints

• 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.

Recovery Algorithm
Recovery Algorithm :

Recovery algorithm using log records for recovery from

transaction failure and a combination of the most recent
checkpoint and log records to recover from a system
crash.

Undo Phase – restores old values

Redo Phase - restores new values

Recovery Algorithm :
Shadow Paging
 Shadow Paging
• Shadow paging is an alternative to log-based
recovery; this scheme is useful if transactions execute
serially.

• Idea: maintain two page tables during the lifetime of

a transaction –the current page table, and the shadow
page table.
 Shadow Paging
• Store the shadow page table in nonvolatile storage,
such that state of the database prior to transaction
execution may be recovered.

– Shadow page table is never modified during

execution

• To start with, both the page tables are identical. Only

current page table is used for data item accesses during
execution of the transaction.
 Shadow Paging
• Whenever any page is about to be written for the first
time

– A copy of this page is made onto an unused page.

– The current page table is then made to point to the

copy

– The update is performed on the copy

Shadow – Copy technique for atomicity & durability

db_pointer db_pointer

Old Copy of New Copy of

Old Copy of
Database Database
Database
(to be deleted )

Before update After update

Shadow – Copy technique for atomicity & durability
Shadow Paging
 Shadow Paging
Shadow and current page tables after write to page 4
Shadow Paging
 Shadow Paging
Advantages :
 No need for log records.

 No UNDO/ REDO algorithm.

 Recovery is faster.
 Shadow Paging
Disadvantages :
 Data is fragmented or scattered.

 Garbage collection problem. Database pages containing

old versions of modified data need to be garbage
collected after every transaction.

 Concurrent transactions are difficult to execute.

 Database Backup
and
Types of Backup
A system failure wipes out all your data, corruption
renders your data useless, an error leads to permanent
deletion.
Remember: Data loss always sneaks up on you.
Types of Database Backup
 Full Differential Incremental

Storage Space High Medium to High Low

Backup Speed Slowest Fast Fastest
Restoration
Fastest Fast Slowest
Speed

Most recent full Most recent full

Media backup & most backup & all
Most recent
Required for recent incremental
backup only
Recovery differential backups since
backup full backup

Stores a lot of Stores duplicate No duplicate

Duplication
duplicate files files files
 Remote Backup Systems
• Remote backup systems provide high availability by
allowing transaction processing to continue even if the
primary site is destroyed.
 Remote Backup Systems (Cont.)
• Detection of failure : Backup site must detect when
primary site has failed

– to distinguish primary site failure from link failure

maintain several communication links between the
primary and the remote backup.

– Heart-beat messages
 Remote Backup Systems (Cont.)
• Transfer of control :

– To take over control backup site first perform

recovery using its copy of the database and all the
long records it has received from the primary.

• Thus, completed transactions are redone and

incomplete transactions are rolled back.

– When the backup site takes over processing it

becomes the new primary
 Remote Backup Systems (Cont.)
• Transfer of control :

– To transfer control back to old primary when it

recovers, old primary must receive redo logs from
the old backup and apply all updates locally.
 Remote Backup Systems (Cont.)
• Time to recover: To reduce delay in takeover, backup
site periodically proceses the redo log records (in
effect, performing recovery from previous database
state), performs a checkpoint, and can then delete
earlier parts of the log.
 Remote Backup Systems (Cont.)
• Hot-Spare configuration permits very fast takeover:

– Backup continually processes redo log record as

they arrive, applying the updates locally.

– When failure of the primary is detected the

backup rolls back incomplete transactions, and
is ready to process new transactions.
 Remote Backup Systems (Cont.)
• Alternative to remote backup: Distributed
database with replicated data

– Remote backup is faster and cheaper, but less

tolerant to failure
 Remote Backup Systems (Cont.)
• Ensure durability of updates by delaying transaction
commit until update is logged at backup; avoid this
delay by permitting lower degrees of durability.

• One-safe: commit as soon as transaction’s commit

log record is written at primary

– Problem: updates may not arrive at backup before it

takes over.
 Remote Backup Systems (Cont.)
• Two-very-safe: commit when transaction’s commit log
record is written at primary and backup

– Reduces availability since transactions cannot commit if

either site fails.

• Two-safe: proceed as in two-very-safe if both primary and

backup are active. If only the primary is active, the
transaction commits as soon as is commit log record is
written at the primary.

– Better availability than two-very-safe; avoids problem of

lost transactions in one-safe.