Database Recovery in RDBMS

·       Database recovery is the process of restoring the database to a correct state in the event of a failure.

·       In other words, it is the process of restoring the database to the most recent consistent state that existed shortly before the time of system failure.

·       The failure may be the result of a system crash due to hardware or software errors, a media failure such as head crash, or a software error in the application such as a logical error in the program that is accessing the database.

·        Recovery restores a database form a given state, usually inconsistent, to a previously consistent state.

·       The database recovery process generally follows a predictable scenario.

·       It first, determines the type and extent of the required recovery.

·       In the entire database needs to be recovered to a consistent state, the recovery uses the most recent backup copy of the database in a known consistent state.

* Types of Database Recovery:-

·       In case of any type of failures, a transaction must either be aborted or committed to maintain data integrity.

·       Transaction log plays an important role for database recovery and bringing the database in a consistent state in the event of failure.

·       Transactions represent the basic unit of recovery in a database system.

·       The recovery manager guarantees the atomicity and durability properties of transaction in the event of failures.

·       During recovery from failure, the recovery manager ensures that either all the effects of a given transaction are permanently recorded in the database or none of them are recorded.

·       The following 2 types of transaction recovery are used:

1)    Forward Recovery.

2)    Backward Recovery.

1    Forward Recovery (or REDO) :-

·       Forward recovery is the recovery procedure, which is used in case of a physical damage,.

·       For example, crash of disk pack, failure during writing of data to database buffers, or failure during flushing buffers to secondary storage.

·       The intermediate results of the transactions are written in the database buffers.

·       The database buffers occupy an area in the main memory. From this buffer, the data is transferred to and from secondary storage of the database.

·       If the failure occurs between writing to the buffers and flushing of buffers to the secondary storage, the recovery manager must determine the status of the transaction that performed the WRITE at the time of failure.

·       If the transaction had already issued its COMMIT, the recovery manager redo so that transactions updates to the database.

·       This redoing of transaction updates is also known as roll-forward.

·       The forward recovery guarantees the durability property of transaction.

·       To recreate the lost disk due to the above reasons explained, the systems begin reading the most recent copy of the lost data and the transaction log og the changes to it.

·       A program then starts reading log entries, staring from the first one that was recorded just before the disk was destroyed.

·       There are a number of variations on the forward recovery methods that are used.

·       In one variation, the changes may have been made to the same piece of data since the last database copy was made.

·       Another roll-forward variation is to record an indication of what the transaction itself look like at the point of being executed along with other necessary supporting information, instead of reading before and after images of the data in the log.

1)    Backward Recovery (or UNDO):-

·       Backward recovery is the recovery procedure, which is used in case an error occurs in the midst of normal operation on the database.

·       The error could be a human keying in a value, or a program ending abnormally and leaving some of the changes to the database that it was suppose to make.

·       If the transaction had not committed at the time of failure, it will cause inconsistency in the database as because in the interim, other programs may have read the incorrect data and made use of it.

·       Then the recovery manager must undo any effects of the transaction database.

·       The backward recovery guarantees the atomicity property of transactions.

·       In the case of recovery, the recovery is started with the database in its current state and the transaction log is positioned at the last entry that was made in it.

·       Then a program reads “backward” through log, resetting each updated data value in the database to it “before image” as recorded in the log, until it reaches the points where the error was made.

·       Thus, the program ‘undoes’ each transaction in the reverse order from that in which it was made.