Explain Data Base Recovery Management ?

Data base recovery restores a data base from a given state (usually inconsistent) to a previously consistent state.

Recovery techniques are based on the atomic transaction property.

That means all portions of the transaction must be treated as a single, logical unit of work in which all operations are applied & completed to produce a consistent data base.

If any reason, any transaction operation cannot be completed the transaction must be aborted & any changes to the data base must be rolled back.

Critical events can cause a data base to become non®operational & compromise the integrity of the data.

Examples of critical events are :

Hardware / software failures : failures of this type could be a hard disk failures, bad capacitors on a mother board memory fail.

Application program or operating system errors that cause data over written, deleted, (or) lost.

Human–caused incidents : This is categorized in to 2- types. Un intentional failures                    Intentional

Un-intentional failures : It is caused by carelessness by end–users.

Errors are :  v  Deleting rows of a table v  Pressing the wrong keys on the keyboard. v  Shutting down the main data base server.

Intentional failures :This indicate company data are at serious risk. v  Security threats caused by lacks trying to gain unauthorized access to data resources & virus attacks etc.

Natural disasters : This category includes fires, earth –quakes , floods & power failures. Various recovery techniques are used to recover the data base from an inconsistent state to a consistent state.

Transaction recovery : It uses data in the transaction log to recover a data base from a inconsistent state to a consistent state.

Write  a head log protocol: This protocol keep the transaction logs are always written before any data base data are actually updated. In case of any failure the data base can later be recovered to a consistent state.

Redundant transaction logs  : It will maintain several copies of the transaction log. A physical disk failures will not effect the DBMS’s ability to recover data.

Database buffers: There  are temporary storage areas in primary memory used to speed up disk operations. To improve processing time the DBMS software reads the data from the physical disk & stores a copy of the data in to buffer. After complete the process, it will update the data in physical disk. Recovery procedures generally uses 1. deterred – write                 2. Write – through techniques

Deterred – write (deterred – update ) : the transaction operations do not immediately update the physical data base. only the transaction log is updated. The data base is physical updated only after the transaction reaches is commit point.

The recovery process follow these steps :

v  Identify the last check point in the transaction log. This is last time the data was physically saved to disk.

For a transaction the started & was committed before the last check point, nothing          needs to be done because the data are already saved.

v  For a transaction that performed a commit operation after the last check point, the DBMS uses the transaction log records to redo the transaction & to update the data base, using the after values in the transaction log.

Write – through(immediate update) The database is immediately updated by transaction operations during the transactions execution , even before the transaction reaches its commit point. The roll back operation will use transaction log before values.

The recovery process follows:

Identify the last check point in the transaction log

The transaction that started & was committed before the last check point, nothing needs to be done because the data we already saved.

For a transaction that was committed after the last check point, the DBMS redoes the transaction using the “after values of the transaction tag”.