Types of Recovery

There are two RECOVERY options available:
datacom151
There are two RECOVERY options available:
  •  
    Forward
    Reapplies maintenance transactions as they are recorded in the Recovery File (RXX). Use forward recovery to bring a database up to date when a restore of a previous backup has been necessary.
  •  
    Backward
    Reverses maintenance transactions recorded in the Recovery File (RXX). Use backward recovery to reverse or back out maintenance that was applied.
     Because SQL DDL statements are not recorded in the Log Area, they are not recoverable using the RECOVERY function of the DBUTLTY. In the case of DDL statements, it is therefore your responsibility to ensure the existence of the Directory (CXX) definitions necessary for recovery.
The following topics are discussed on this page:
 
 
When to Use
Use forward recovery when your database has been partially or fully destroyed or is unusable. Use backward recovery when you want to reverse transactions from the current status of the database.
 The RECOVERY function supports tapes from the GDG (Generation Data Group).
Use of URI
We recommend the Unique Row Identifier (URI) record ID format for all environments. Using the URI format reduces manual intervention during recovery. You can convert to the URI format using a data area LOAD (see LOAD (Build a Data Area)).
RANGEDT= Keyword
The RANGEDT= keyword gives you a clean and complete method of restricting a forward or backward recovery effort to a single limited time period.
For more information about the RANGEDT= keyword, see Optional Keywords following Forward Recovery 
.
 
FORCE= Keyword
The FORCE= keyword in forward or backward recovery gives you a way to specify whether the recovery utility allows input without the first record being a CYCLE START.
For more information on the FORCE= keyword, see Optional Keywords following Forward Recovery 
.
 
For backward recovery, note that the MISMATCH= keyword is required.
MULTUSE= Keyword
In support of area level DBUTLTY control (see Area Level DBUTLTY Control), using MULTUSE=YES in the RECOVERY OPTION=FORWARD function allows a single area in a database to be recovered with no disabling of the other areas in the database. Forward recovery functionality that existed in versions prior to Version 11.0 remains unchanged. For more information on the MULTUSE= keyword, see Optional Keywords following Forward Recovery 
.
 
If MULTUSE=YES has not been specified, no other task can be processing the database when you are running forward RECOVERY.
RECID= Keyword
The optional keyword RECID=, when set to NO, allows forward recovery to be based on the Master Key instead of the row identifier. Using RECID=NO is not for "normal" recovery applications. For more information, see Optional Keywords following Forward Recovery 
.
 
Impact of Data Area Reorganization
The forward and backward recovery operations require that record location information in the database match the record location information that existed at the time the maintenance was performed. A reorganization of the database causes new record location information to be assigned. Therefore, any reorganization causes Recovery File(s) (RXX) created prior to the reorganization to be unusable.
RXXs without End-of-File or Trailer Records
If the operating system or the MUF terminates abnormally while 
CA Datacom®/DB
 is writing to a Recovery File (RXX), the tape has no End-of-File or trailer records.
When you restart the MUF, DBUTLTY detects the condition and reports the last completed cycle number. The restart process then changes the cycle and the log blocks being spilled from a 
being spilled
 status to a 
needing to be spilled
 status. A later spill can then copy these blocks in their entirety.
Two problem situations exist at this point:
  • Because no trailer records exist on the active recovery tape, recovery processing with this tape is a problem. Backward recovery cannot function at all because the trailer records cannot be found. Forward recovery can function, but the recovery receives an I/O error.
  • The second problem is that when executing forward recovery, the next Recovery File after the one with no End-of-File, detects errors because of the duplicated log records which require review.
To eliminate these problems, execute the RXXFIX function (see RXXFIX (Recover End-Of-File)).
Backups for Use with Forward Recovery
To use the 
CA Datacom®/DB
 forward recovery to recover a data area, the records in the database must be restored to the same physical locations at which they resided at the time the recovery records were logged. You can obtain a backup that contains the records that can be restored correctly in one of two ways:
  • Use the BACKUP Data Area option with SEQ=PHYSICAL and RECID=YES to create a backup in physical sequence with record location information.
  • Create a backup in Native Sequence and immediately restore it. This reorganization invalidates any Recovery Files (RXX) that were made prior to the backup. However, any Recovery Files created beyond this point can be used to restore the database after reloading this backup.
A physical sequence backup can also be obtained using any other physical backup utility. This type of backup cannot be used directly as input to the DBUTLTY LOAD function. After restoring data from this type of backup, the Index can be restored using the DBUTLTY Reconstruct Index (RETIX) function.
 Forward recovery expects to be executed after an area restore. It is not intended to be executed after a backward recovery. This requirement is especially true when running without the URI option.
Forward recovery into areas that have been dynamically or manually extended require that the data set size reflect all tracks that previously existed. Forward recovery into an area that does not reflect all extended tracks may receive a return code 94(086). This is true when running the RECOVERY function with the MULTUSE= keyword set to YES or NO. A forward recovery execution does not successfully dynamically extend a data set. The 94(086) return code should occur. Log records used in this recovery process could contain recovery information from the missing extended tracks causing the error.
Continuous Processing
To continue processing during a backup, you must use the physical backup method with UPDATE=NO specified. If maintenance processing occurs during the backup, error messages are to be expected when a subsequent forward recovery is used to restore the database. You should only receive errors for maintenance that occurs during the time span that the backup was run. Carefully examine these errors to be sure that all maintenance is properly restored. 
Processing Multiple Recovery Files
Multiple recovery files can be processed in a single execution of the utility. Specify the files using normal JCL. The files concatenate in the order in which they are created.
Backward Recovery
Backward recovery requires no database preparation. The backward recovery process alters the database by reversing maintenance transactions, returning it to its unchanged state.
RECOVERY OPTION=BACKWARD performs by reading the selected data forward using the name RXX and sorting it into reverse sequence.
You can use the STIME= and ETIME= keywords to reverse part of a job, but this is not a recommended technique. Examine any backward recovery, other than an entire job, carefully.
MUF Connection
This function communicates with one MUF. Be aware of the following:
  • Ensure that DBUTLTY is communicating with the desired MUF by executing DBUTLTY with the same System Identifier module (DBSIDPR) that is being used by the MUF, and
  • Ensure proper load library concatenation by keeping the System Identifier modules (DBSIDPR) in separate load libraries.
If the z/OS Cross-System Coupling Facility (XCF) is being used, ensure that the TOGROUP DBSIDPR parameter is correctly defined. 
Impact of Integrity Constraints (Forward Recovery)
The impact of integrity constraints on the forward recovery process depends on whether all dependencies of all tables in the database are contained within that database. During the recovery process, if all dependencies of all tables are contained within the database in question, and you have 
not
 requested individual table recovery or selected a subselect of the recovery (such as, by job name), the system assumes that integrity is not violated.
In all other cases, tables defined with integrity constraints which are processed by the recovery function are marked CHECK-PENDING, indicating that referential integrity must be checked (see CONFIRM (Verify Constraint Integrity)). Applications attempting to access such tables may receive a return code, as indicated in the following chart:
 
For forward recovery:
 
 
Then:
 
If a table references another table (is a child)
DELETES are allowed, but ADDS and UPDATES generate a CHECK-PENDING return code.
If a table is referenced by another table (is a parent)
ADDS are allowed, but DELETES and UPDATES generate a CHECK-PENDING return code.
 You must CONFIRM tables in the following order, from referenced-to-referencing, or parent-to-child, that is to say, the referenced table cannot be in check pending status. For example, if there is a foreign key from a REMARKS table to a LINE_ITEM table on PO_Nbr and Line_Item_Nbr, and the LINE_ITEM table has a foreign key that references the PO table on PO_Nbr, the PO table must be loaded first, then the LINE_ITEM table can be confirmed, then the REMARKS table can be confirmed. Therefore, the confirm order would be: from PO table to LINE_ITEM table to REMARKS table.
Impact of Integrity Constraints (Backward Recovery)
Backward recovery exists in the MUF with all normal constraint checking in force.
Index Option
For all backward recoveries and most forward recoveries, it is most efficient to perform Index maintenance with the data maintenance. That is, for each record added, the required Index entries are also added. At the completion of the recovery, all work is done and the data and Index are synchronized.
In special situations where most of an area is added or deleted (or updated with key changes), this conventional way of handling Index maintenance may not be the fastest process. The conventional process also may not be the best if key fields are frequently changed during the day and for tables with many keys.
With the INDEX= keyword, you specify whether the backup is loaded in the conventional manner or with no Index maintenance. You cannot run the function with an initialized-only Index or a wrong Index. The URI Index and space Index are required to be accurate. After loading the data areas, the forward recovery would also be done without Index work (INDEX=NO). At the completion of the recovery, you run the RETIX function on each database recovered to build its Index for the data records.
How to Use Backward Recovery
The MUF must be active when you execute this command. To use the DBUTLTY RECOVERY function for backward recovery, submit at least the RECOVERY command. The RECBASE command is optional. If you specify a RECBASE command, you limit the recovery to the tables in a single database or to a specific table, otherwise the RECOVERY function opens tables as necessary. If you do not specify an optional RANGEDT keyword, 
all
 the jobs accessing the DBID specified in the RECBASE command(s) are recovered. Do not specify a RANGEDT keyword for continuous operations.
Backward Recovery Successful Execution Requirements/Controls
 
Environmental
 
Requirements
 
 Rules are the same as a user application opening a table to update records.
  • The database may or may not be open for update in the connected MUF.
  • The database may 
    not
     be open for update in another MUF or Single User job.
  • The database may 
    not
     have any table in 
    unloading
     status.
  • The database ACCESS must be set WRITE/UTLTY.
  • The area ACCESS must be set WRITE/UTLTY.
  • The area may 
    not
     have BACKUP, EXTEND, EXTRACT, INIT, LOAD, RECOVERY, REORG, REPLACE, or RETIX with MULTUSE=YES executing.
 
Environmental
 
Controls
 
  • The database will be opened by MUF for update.
  • The utility does 
    not
     set ACCESS area.
  • The utility does 
    not
     set RECOVERY executing this MUF this database or area.
How to Use Forward Recovery
Forward recovery can be run in an active MUF mode for one area or in a Single User mode while the MUF is up, providing that the database is not being used. To use the DBUTLTY RECOVERY function for forward recovery not by area, you must submit at least one RECBASE command and only one RECOVERY command. You can use an optional RANGEDT keyword to define a 
date/time-range.
 The first date/time is the lowest time to process and the second date/time is the highest time to process.
The JOBNAME= keyword allows you to specify RECJOB commands.
If you do not specify a RANGEDT keyword, 
all
 the jobs accessing the DBID specified in the RECBASE command(s) are recovered. For continuous operations, do not specify a RANGEDT keyword.
Impact of Table Partitioning
For information about the impact of table partitioning on the forward recovery function, see Forward Recovery Utility.
Forward Recovery Successful Execution Requirements/Controls
 
Environmental
 
Requirements
 
when MULTUSE=NO, Simplify NO, or MUF down
 
  • The database may 
    not
     be open for update anywhere.
  • The database may 
    not
     be open in any MUF for read.
  • The database may 
    not
     have any table in 
    unloading
     status.
 
Environmental 
 
Requirements
 
 when MULTUSE=NO, Simplify YES, and MUF enabled
 
  • The database may be open for update but must have no users.
 
Environmental
 
Controls
 
when MULTUSE=NO,Simplify NO, or MUF down
 
  • The database will be opened for update.
  • The utility has no knowledge about current ACCESS database or area status.
  • The utility sets no ACCESS database or area status.
 
Environmental 
 
Controls
 
 when MULTUSE=NO Simplify YES and MUF enabled
 
  • The database will be opened for update if not already.
  • All areas will be closed if open.
  • The utility will execute with every ACCESS database or area status.
  • The utility sets protection to block other incompatible DBUTLTY functions.
 
Environmental
 
Requirements
 
when MULTUSE=YES
 
  • The database may or may not be open for update in the connected MUF.
  • The database may 
    not
     be open for update in another MUF or Single User job.
  • The database may 
    not
     have any table in 
    unloading
     status.
  • The database ACCESS must be set OPTIMIZE and WRITE/UTLTY.
  • The area ACCESS must be set WRITE/UTLTY.
  • The area may have no table in an open User Requirements Table.
  • The area may 
    not
     have any other MULTUSE=YES utility executing.
  • The area must be closed.
  • When MULTUSE=YES, this function will not be allowed against a Data Sharing MUF if more than one is executing.
 
Environmental
 
Controls
 
when MULTUSE=YES
 
  • The database will be opened by MUF for update.
  • The utility sets ACCESS area OFF (utility set).
  • The utility sets RECOVERY executing this MUF this database or area.