Database Recovery

Database Recovery

The database recovery manager component of DBMS is responsible for database recovery from any type of failure. It ensures that atomicity and durability properties of a transaction are maintained.

Types of failure 

1. Transaction failure 

The transaction can no longer continue to execute with its normal execution because of some internal conditions such as bad input, data not found, overflow.

The transaction can also fail when database system enters deadlock state.

2. Software failure

It includes operating system failure DBMS failure. 

3. Hardware failure 

It includes failure of hard disk, ram, input output devices et cetera.

4. Natural or artificial disaster

Such as fire, flood, bomb blast, terrorist attack etc.

Concept of stable storage 

It is a storage in which information will never be lost. This concept is realised through RAID redundant array of integrated disc.

Note - Database recovery can be possible only when stable storage exists.

Types of database recovery

1. Log based recovery 

2. Shadow paging

Log based recovery 

In this we maintain transaction logs on stable storage. The log is a sequence of log records recording all the update activities made by the transaction in the database. Each transaction writes log records on to log file.

Types of log records 

1. Start log 

This log is written by a transaction when its execution is started.

2. Commit log

This log is written when a transaction is successfully completed.

3. Update log

This log is written when any update activity is performed by the transaction.

Recovery schemes in log based recovery

1. Deferred database modification

 In this all database modifications are deferred till the transaction partially commits. 

It maintains three types of logs

1. Start log <Ti,starts>

2. Commit log <Ti,commits>

3. Update log <Ti,dataItem,newValue>

Redo operation is used for database recovery this operation sets the data item to its new value specified in the log.

If a transaction Ti has both start and commit log, then we redo Ti, if only start log is present in the log file, then the transaction Ti has to be restarted.

Example

Note - redo operation is performed in the forward direction from star to end of log file.

2. Immediate database modification 

In this database is immediately modified whenever write operation is performed by the transaction on the database.

It maintains three types of logs

1. Start log <Ti,starts>

2. Commit log <Ti,commits>

3. Update log <Ti,dataItem,oldValue, newValue>

Redo operation and undo operation is used for database recovery.

 Redo operation sets the data item to its new value specified in the log. Undo operation restores old value of data item.

If a transaction Ti has both start and commit log, then we redo Ti, if only start log is present in the log file, then the transaction Ti has to be undone first and then restarted.

Example

Shadow paging 

It is a technique for maintaining atomicity and durability property of a transaction. It does not require maintenance of log file in this the database is partitioned into fixed length of blocks referred to as pages. The page table has  N entries.

One for each database page. Each page table entry contains pointer to a page on disk.

The basic idea is to maintain two page tables current page table and shadow page table.

When transaction starts both page tables are identical. Update is written to a new page and current page table is changed accordingly. The shadow page table is never change during the lifetime of the transaction.

The current page table may be changed whenever a transaction performs a write operation.

If transaction commits current page table is written to shadow page table. In case of transaction failure we revert to shadow page table.

example

No undo or redo operation needed. In fact no recovery is needed in shadow paging scheme.

Features of shadow paging 

1. no overhead for maintaining logs.

2. No undo redo operation needed 

3. faster database recovery ( no recovery needed)

4. fragmentation of pages on the database.

5. Garbage collection of old pages 

6. Commit overhead is large 

7. Suitable for serial execution not for interleaved parallel execution

8. More costly affair than log based recovery