9

21
Recovery

Transcript of 9

Page 1: 9

Recovery

Page 2: 9

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

Page 3: 9

3

Failure Classification

n occurs 10-100 times in a minute

n recovery required in transaction execution time

Page 4: 9

4

n occurs several times a week

n recovery required in a few minutes

Failure Classification

Page 5: 9

5

n occurs intermittently

n recovery time depends on the nature of failure

Failure Classification

Page 6: 9

6

n occurs once or twice a year

n recovery required in a few hours

Failure Classification

Page 7: 9

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.

Page 8: 9

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

Page 9: 9

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

Page 10: 9

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

Page 11: 9

11

Redo Recovery

old consistentversion

new consistentversion

roll-forwardusingafter-images

Page 12: 9

12

Rollback Recovery

current corruptverion

rollbackusingbefore-images

old consistentverion

Page 13: 9

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

Page 14: 9

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

Page 15: 9

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

Page 16: 9

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

Page 17: 9

17

Shadow Paging Scheme

currentpage map

shadowpage map

fixed pointer

Page 18: 9

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

Page 19: 9

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

Page 20: 9

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

Page 21: 9

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