Recovery

2

Recovery Systemn Failure classification

n Log based recovery

n Redo recovery

n Rollback recovery

n Immediate update scheme

n Deferred update scheme

n Checkpoints

n Shadow paging

n Backups

3

Failure Classification

n occurs 10-100 times in a minute

n recovery required in transaction execution time

4

n occurs several times a week

n recovery required in a few minutes

Failure Classification

5

n occurs intermittently

n recovery time depends on the nature of failure

Failure Classification

6

n occurs once or twice a year

n recovery required in a few hours

Failure Classification

7

Isolation

Consistency

ACID Properties

takes the database from a consistent state to another consistent state.

The intermediate updates should not be visible to other concurrent transactions until it is COMMITTED.

The changes to the database COMMITTED by itshould not be lost through any subsequent failure.

Durability

Atomicity is atomic; its effect on the database is either TOTAL or NONE.

8

Transaction States

Start

Read Ram’s account

Debit Rs. 5000

Update Ram’s account

Read Sita’s account

Credit Rs. 5000

Update Sita’s account

End

active

partiallycommitted

failed abortedfailed aborted

How do I get the databaseback to its consistentstate?

How do I get the databaseto its final consistent

state?

committed

9

The Problem: Buffering!

Start

Read Ram’s account

Debit Rs. 5000

Update Ram’s account

Read Sita’s account

Credit Rs. 5000

Update Sita’s account

End

R: 15000 S: 45000in

memoryon

disk

1500015000

10000 15000

10000 15000?

4500045000

50000 45000

50000 45000?

R: 10000 S: 50000

10

Log-based Recovery

n maintain a log of incremental updates

n update log before updating the database record

n use synchronous write on log; this may be expensive - so, most DBMS‘s use special techniques to block log records

n log can easily get voluminous; periodic purging or cyclic reuse resorted to

n each record minimally contains trans id, data id, old value, new value, timestamp

11

Redo Recovery

old consistentversion

new consistentversion

roll-forwardusingafter-images

12

Rollback Recovery

current corruptverion

rollbackusingbefore-images

old consistentverion

13

The Immediate Update Scheme

n undo the last partial transaction using the before entries

n redo all the past committed transactions in the forward direction using the after entries

n undo and redo are idempotent; this is important to recover from failure during the recovery process

14

The Deferred Update Scheme

n redo all the past committed transactions in the forward direction using the after entries

n potentially heavy I/O at Commit: reads from log file and updates on database file

n undo and redo are idempotent; this is important to recover from failure during the recovery process

15

Checkpoints

n log keeps growing with the age of the session

n recovery gets very time-consuming

n most of the efforts are really wasteful since the updates are already on the disk, but cannot be avoided since there is no way of knowing where to start

16

Checkpoints

n Stop accepting new transactions

n Suspend execution of transactions temporarily

n flush out all log records onto log file

n flush out buffer blocks to database

n flush out <checkpoint> log entry onto log file

n redefine the last checkpoint as the start of the recovery process

17

Shadow Paging Scheme

currentpage map

shadowpage map

fixed pointer

18

Shadow Paging Scheme

n To commit a transaction :

1. Flush all modified pages in main memory to disk

2. Output current page table to disk

3. Make the current page table the new shadow page table, as follows:n keep a pointer to the shadow page table at a fixed

(known) location on disk.

n to make the current page table the new shadow page table, simply update the pointer to point to current page table on disk

19

n Once pointer to shadow page table has been written, transaction is committed.

n No recovery is needed after a crash —new transactions can start right away, using the shadow page table.

n Pages not pointed to from current/shadow page table should be freed (garbage collected).

20

On-line Backups

n set database to offline moden flush out all log records onto log filen flush out <start backup><start backup> onto log filen maintain backup log versionn flush out buffer blocks to databasen copy database to backup filen set database to online mode and update

database using backup logn flush out <end backup><end backup> onto log file

21

Off-line Backup (Dumps)

n Media Failure

n Restore from earlier backup by DBA

n Backup utilities available

n BACKUP DATABASE

n Complete vs Differential

n Replication Server