Data Protection - Lecture Note IV (Database Recovery)

Recovery in a database system means primarily, recovering the database itself that is, restoring the database system to a state that is known to be correct after some failure has rendered the current state incorrect, or at least suspected.

The underlying principles on which such recovery is based are quite simple, and can be summarized in a single word - Redundancy (redundancy, that is at the physical level; any such redundancy should of course be hidden from the user and thus not visible at the logical level).

Transaction

• A transaction is a logical unit of work.
• Thus a logical unit of work (i.e. Transaction) is not necessarily just a single database operation; rather, it is a sequence of - several such operation.
• In general, that transforms a consistent state of the database into another consistent state.

A system that supports transaction management does provide the next best thing to such a guarantee. Specifically, it guarantees that if the transaction executes some updates and then a failure occurs before the transaction reaches its planned termination, then those updates will be undone. Thus the transaction either executes in its entirety or is totally canceled.

The system component that provides this atomicity is known as the transaction manager and COMMIT and ROLLBACK are the key to the way it works:

• The COMMIT operation signals successful end of transaction. lt ,tells the transaction, manager that a logical unit of work has been successfully completed, the database is in a consistent state again, and all of the updates made by the logical unit of work can now be Committed or made permanent;
  
• By contrast, the ROLLBACK operation signals unsuccessful end-of- transaction: It tells the transaction manager that something has gone wrong, the database might be in an inconsistent state, and all of the update made by the logical unit of work so far must be "rolled back" or undone.

In the example, therefore, we issue a COMMIT if we get though the two updates success{ully, which will commit the changes in the database and make them permanent. lf anything goes wrong, however- i.e., if either update raises an error condition-than we issue a ROLLBACK instead, to undo any changes made so far.

Transaction Recovery

• A, transaction, beings with successful execution of a. BEGIN TRANSACTION statement, and it ends with successful execution of either a COMMIT or a ROLLBACK, statement.
  
• A COMMIT point thus corresponds to the end of a logical unit of work.
  
• ROLLBACK, by contrast, rolls the database back to the state it was in at. BEGIN TRANSACTION, which effectively means back to the previous commit point.
  
• In the figure 1 example, we include explicit test for error and issued an explicit ROLL BACK if any error was detected .But of course, the system cannot assume that application program will always include explicit-test for all possible errors.
  
• Therefore the system will issue an implicit ROLL BACK for any transaction that fails for any reason to reach its planned termination.
  
• We can see, therefore the transaction are not only a unit of work but also the unit of recovery .For if transaction successfully commits, then system will guarantee that its updates ,will be permanently installed in the database even if the system crashes the very next moment.
  
• It is quite possible, for instance, system might crash after the COMMIT has been honored but before the update have been physically written to the database.- they still might, be waiting in a main memory buffer and so be lost at the time of the crash. Even if that happens, the system's restart procedure will still install those updates in the database; it is able .to discover the values to be written by examining the' relevant entries in the log .(it follows that. the log must be physically written before COMMIT processing can complete - the write ahead log rule/Protocol). Thus the restart procedure will recover any, transactions 'that completed successfully but did not manage to get their updates physically written prior to crash; hence as stated earlier, transactions are indeed unit of recovery.

What is a backup file ?

A backup file is a copy of the original file which is kept away from the original to replace the originalfile in case it is lost or damaged.

Transaction file log

A list of all changes made to a database since the contains transaction details which could be used damage to the main file.

How should backup files be stored?

• Away from the originals (physical distance) 
• ln secure storage locations (q: Safe boxes)
• ln secure 3rd party storage locations
• ln encrypted form
• Away from potential environmental hazards. (eg : Water)