Introduction Recovery Techniques | Database Management System

Introduction Recovery Techniques | Database Management System

Introduction Recovery Techniques : Recovery implies restoring the database to a state that is assumed to be correct, after Some failure has rendered the current state incorrect (or at least suspect). Recovery is made possible by the underlying redundancy at the physical level. This redundancy should be hidden from the user and thus should not be visible at the logical level. A database is recoverable, if every piece of information that the database contains, can be reconstructed from some other information stored redundantly somewhere else in the System.

Transactions: A transaction is a logical unit of work.

Example: Transfer an amount of R 1000 from ACCOUNT# 100 to ACCOUNT# 200.

BEGIN TRANSACTION:
UPDATE ACCOUNT WHERE ACCOUNT IF any error THEN GO TO UNDO,
‘100’ BALANCE := BALANCE -1000;
UPDATE ACCOUNT WHERE ACCOUNT IF any error THEN GO TO UNDO,
200 BALANCE := BALANCE + 1000;
COMMIT TRANSACTION:
GOTO FINISH;
UNIDO: ROLLBACK TRANSACTION;
FINISH: RETURN;

So, the transaction involves two updates (an update includes INSERT, DELETE and UPDATE) to the relation ACCOUNT. The database is not consistent between the two updates. Temporarily, the total balance at the BRANCH would not be correct, but at the end of the transaction it would tally.
So, we can state that a Transaction transforms a consistent state of the database into another consistent state, without necessarily preserving consistency at all intermediate steps. What happens if the first update is executed and the other not? The database would be left in an inconsistent state. The aim is that a transaction should be either executed in its entirety or cancelled totally. So, if a transaction executes some of its updates and then a failure occurs before the transaction reaches its planned termination, then those updates should be undone (called ROLLBACK). The System component that provides this atomicity to transaction processing is called transaction manager.

Commit Transaction

This operation signals successful end-of-transaction. It confirms to the transaction manager that atransaction has successfully completed, database is in a consistent state again, and all updates made by the transaction can now be ‘committed’ i.e., made permanent.

Rollback Transaction

This operation signals unsuccessful end-of-transaction. It indicates to the transaction manager that a transaction has failed to complete due to some failure, database may be in an inconsistent state, and all updates made by the transaction be “rolled back” i.e. undone.

How to undo the updates in case of ROLLBACK?

System maintains a log (or journal) on disk/tape, which contains details of all update operations. The pre-update and post-update values of the updated objects are recorded in the log. In case of rollback, system uses the log to restore the values to pre-update state. The log is maintained in two portions- an active or online log which is maintained on disk and an archive or off-line log which is maintained on tape. The online log is used for minor recovery during normal System operation. When the size online log on the disk reaches some preset limit, it is transferred to offline log on a tape. All updates performed after the last backup (or dump) has been taken are saved on the offline log, which are used to restore the system from the last backup in case of major failures.