Utility Statements › ROLLFORWARD › Usage

Usage

How to submit ROLLFORWARD

You submit the ROLLFORWARD statement only through the batch command facility. When submitting ROLLFORWARD statements, you must run the batch command facility in local mode.

Vary any area being rolled forward offline to all central versions.

When to use ROLLFORWARD

The ROLLFORWARD utility is most commonly used to restore a database to its condition before some hardware problem corrupted the database. In this case, use a backup copy of the database that was created before the problem occurred.

You must have a backup of the database from a time before the problem, as well as all relevant journals.

Note: For more information about when and how to use the ROLLBACK and ROLLFORWARD utilities, see the CA IDMS Database Administration Guide.

How ROLLFORWARD works

The ROLLFORWARD operation starts with a former state of the database, as captured by a backup. It uses after images from a tape or journal file to restore progressively later states of the database, file, segment, or area.

ROLLFORWARD uses one journal file

The journal file is a sequential file that can reside on disk or tape depending on which options are specified. If you specify SEQUENTIAL, the journal file must reside on tape; if you specify SORTED, the journal file can reside on disk or tape. If you have multiple journal files, you must consolidate them, in the order in which they were created, to a single file and use the single file with the ROLLFORWARD utility.

If the file requires more than one tape volume, the volumes must be mounted in order.

ROLLFORWARD and VSAM files

You can run the ROLLFORWARD utility against native VSAM files.

When to use sorted mode

Use sorted mode unless you have a strong reason not to. Be sure you have enough sort space available before executing the ROLLFORWARD utility. If, however, you run out of sort space, the ROLLFORWARD operation will terminate with an error and the database will not be affected.

Note: You cannot use sorted mode when applying the journal images created while a hot backup was in progress. For more information about recovering from a hot backup, see the CA IDMS Database Administration Guide.

ROLLFORWARD FROM EXTRACT

• Purpose—Much of the work of recovery can be performed by EXTRACT JOURNAL during a noncritical time. The actual recovery done by ROLLFORWARD will be relatively fast because the extract file will contain only the records needed for recovery, in correct sort order.
• Extract data—Data in the extract file is selected and sorted before the actual recovery is done by ROLLFORWARD. A second sort is performed by ROLLFORWARD so that only the most recent image for each db-key is applied to the database.
• Multiple input files—Multiple input files can be processed as standard concatenated files; they do not need to be merged into one file before processing.
• Tape file—Since the extract file does not need to be read backwards, it does not need to be on tape.

Controlling the starting point of the rollforward operation

If no START AT parameter is specified, the rollforward operation starts with the first journal image on the input file(s). If START AT is specified, the rollforward operation starts with the first checkpoint record (BGIN, COMT, ENDJ, ABRT, or CKPT) whose timestamp is on or after the specified start time.

Specifying a start time may save recovery time and also circumvent issues associated with aborted recovery units that span the start of the input file. It further enables the rollforward operation to begin processing at a quiesce point that does not correspond with a journal file boundary.

Quiesce point verification

A quiesce point is a point in time during which there is no update activity for some portion of a database. To perform a correct recovery, you must begin the recovery operation at a quiesce point for the portion of the database being recovered. To assist in this effort, the rollforward utility provides two levels of quiesce point verification: limited and full.

Quiesce point verification is always performed during a rollforward operation. This is done by checking for the existence of spanned recovery units, which are recovery units that are active at the start of the rollforward operation. A recovery unit is represented by journal images starting with a BGIN or COMT checkpoint and ending with a COMT, ENDJ, or ABRT checkpoint. If a spanned recovery unit updates the specified portion of the database, then the rollforward operation is not starting at a quiesce point. If this situation is detected, the rollforward operation will terminate with an error.

However, it is not always possible to know whether a spanned recovery unit affects the specified portion of the database or not. If the initial BGIN or COMT checkpoint record for a recovery unit is not contained on the archive file being processed, then it is not possible to determine whether it updated the specified portion of the database. Such a recovery unit is referred to as an indoubt recovery unit.

The time line illustrates what is meant by an indoubt recovery unit. The journal images for recovery unit R are written to the journal file at the times shown. If the archive file includes images starting at time T1, then R is not an indoubt recovery unit because the archive file contains all journal images written for R since its inception. Similarly, if the archive file starts at time T3, R is not an indoubt recovery unit, because the archive file contains no images for R whatsoever. However, if the archive file starts at time T2, then R is an indoubt recovery unit, since the archive file does not contain all journal images written since its inception.

If an indoubt recovery unit does not span the start of the rollforward operation, its existence doesn't matter. But if an indoubt recovery unit is also a spanned recovery unit, then the rollforward operation may not be starting at a quiesce point.

The action taken if an indoubt spanned recovery unit is encountered depends on whether limited or full quiesce point verification is in effect. Under full verification, the rollforward operation will terminate with an error. Under limited verification, a warning message will be issued identifying the recovery unit, but processing will continue.

Warning messages produced under limited verification should be examined to ensure that the identified recovery units in fact did not affect the specified portion of the database. If there is any doubt, the PRINT JOURNAL utility statement should be used to gain more information about the indoubt recovery units. If, after researching the situation, it is found that an indoubt recovery unit did update the specified portion of the database, the affected portion of the database must be restored and the rollforward operation repeated. You must locate a quiesce point corresponding to a backup of the specified portion of the database and begin the rollforward operation from that point.

When to use full or limited verification

Full quiesce point verification should be used only if you expect that no indoubt spanned recovery units are active at the starting point of the rollforward operation. The only way to guarantee this is to process archive files that were created immediately following a quiesce of update activity across all areas. One way to establish such a quiesce point is to shutdown a central version. Another way is to use the DCMT QUIESCE command and specify a DBNAME that includes every area in the DMCL.

Limited quiesce point verification can be used when processing the archive files produced immediately following a quiesce operation for the portion of the database being recovered. One way to do this is to use the DCMT QUIESCE SEGMENT command to quiesce a segment and then use limited quiesce point verification when recovering all or a portion of that segment.

When to use VERIFY DATABASE

Specify VERIFY DATABASE only when rolling forward from an intact database.

Recovering large numbers of files

For z/OS users, the maximum number of files that can be accessed by a central version is greater than the number that can be accessed by a local mode batch job. This has implications for manual recovery. If more than 3,273 files must be recovered, it will be necessary to execute the ROLLFORWARD utility multiple times in separate job steps, recovering a subset of the areas or segments in each execution.

ROLLFORWARD and Distributed Transactions

ROLLFORWARD reports on distributed transactions and supports the use of input and output manual recovery control files. Unless ALL is specified, the input manual recovery control file is used to complete InDoubt distributed transactions. If an output manual recovery control file is included in the JCL, unless FROM EXTRACT is specified, an entry is written for each incomplete distributed transaction encountered. For more information, see JCL Considerations and the "Common Facilities for Distributed Transactions" appendix.

Note: For considerations associated with distributed transactions during recovery operations, see the CA IDMS Database Administration Guide.