Recovery Concepts

Transaction Boundaries

The Recovery Management Facility provides the processing used to mark transaction boundaries for all system file updates.  Two boundary markings provide an audit trail of system processing that can be used to restore system files to their original state prior to a system failure.  The Commitment Control Facility provides one method of performing this function.  Commitment control is used to mark transaction boundaries in online programs with less than 1,024 updates in a transaction.  Due to inherent restrictions in commitment control processing, the Recovery Management Facility creates user journal entries to mark boundaries for batch update applications, and online applications with more than 1,024 updates.

Recovery Methods

Two recovery methods are provided by the Recovery Management Facility, rollback and roll forward.  The recovery method used after a system failure is determined by the type of failure, and the amount of damage done to system objects.  The recovery options available for each type of failure are described below.

·     CPU Failure.  Whether caused by a hardware malfunction, power outage, or manual intervention, a CPU failure almost always corrupts system files. 

—   If there is physical damage to the hardware or disk (system files or journal are damaged), roll forward processing must be performed.  This process is discussed in the following point, disk failure. 

—   If system files are not damaged, the recovery objective is to reset the data base as of the last complete update made by each conversation or batch program.  The Journaling Facility ensures that the system journal is synchronized with all journaled files.  The Commitment Control Facility ensures that all uncommitted transactions are rolled back.  The Recovery Management programs identify in-flight batch transactions (those with a starting user journal entry but without an ending entry) and remove the effect of those transactions.  User recovery for online processing involves re-entering those transactions that were in-flight, and then continuing with subsequent transactions.  Most batch processing would have to be re-executed, since batch program execution is viewed by the system as one large update.

·     Disk Failure.  Lost or damaged files require the reloading of the last saved version of the system files, and the re-application of journaled updates to the last complete update prior to the failure.  After the system files have been restored, the journal receiver attached to the journal must be inquired upon by the user.  The existence of the journal receiver must be verified.  If the journal receiver exists, the journal attributes must be displayed to determine if the receiver was damaged during the disk failure.

—   If the journal was lost or damaged, re-application processing cannot be performed.  In this case, all transactions processed since the previous backup must be re-entered into the system.  Also, all batch jobs run since the last backup must be re-executed.  Care must be taken to enter transactions and run batch jobs in the same order in which they were originally performed.

—   If the journal receiver has not been damaged or lost, updates made to system files can be re-applied using the roll forward process.  Transaction entry begins with the last transaction processed before the disk failure occurred.  Batch jobs in process when the failure occurred must be rerun.

·     Workstation Failure.  The recovery technique used for a workstation failure will differ based on the function being performed when the failure occurs. 

—   If a failure occurs when an operator is entering or validating transaction data, the data will be lost, and the transaction must be re-entered from a working terminal.

—   If the failure occurs during "end transaction" processing, the transaction may or may not have been completed.  Commitment control will roll back the changes if the transaction is incomplete.  In this case, transaction entry begins with the transaction being entered at the time of failure.  If the transaction was completed prior to failure, transaction entry begins with the next transaction.