How to submit EXTRACT JOURNAL
EXTRACT JOURNAL must be submitted through the batch command facility and in local mode.
When to use EXTRACT JOURNAL
EXTRACT JOURNAL is most commonly used on a daily basis or after each archive journal is created. It is used as part of a plan for recovering a file or area on a device that takes a hardware hit.
Note: For more information, see the 'FROM EXTRACT' option on the ROLLFORWARD command. It allows ROLLFORWARD processing to be done during a recovery situation when time is critical or extract processing to be done during a non-critical time in case it is needed.
How EXTRACT JOURNAL works
EXTRACT JOURNAL works much the same as ROLLFORWARD using the sort option, except that instead of applying the latest after image directly to the database, the image is written to the extract file. The input archive journal is read and after images for selected areas are sorted. Only the latest image from a completed transaction is saved, and the rest are discarded. By saving only the latest after images for only selected areas, the resulting extract file is smaller and presorted, making subsequent ROLLFORWARD processing go much faster.
If a transaction does not end on the current set of input files, all AFTR images from that transaction are written to the extract file. When these extra images are processed by a subsequent EXTRACT JOURNAL or by a ROLLFORWARD command, they are included with completed AFTR images or discarded depending on the final status of that transaction. Only the most recent AFTR image taken from a completed transaction for a given dbkey is applied to the database.
Multiple input archive journals
Multiple input archive journals can be used as input provided they are read in the correct order. They do not need to be merged into a single file. With restrictions, each archived journal can also be processed with separate EXTRACT JOURNAL jobs, and the resulting extract files can be concatenated as input to one ROLLFORWARD job.
COMPLETE and ALL with STOP time considerations
If the COMPLETE option or the ALL option with a STOP time is specified, the resulting extract file will not contain any information for run units that were active at the end of the archive file. Therefore, an extract file created with these options should never be used as input with extract files created from subsequent archive journals. Use these options only if you intend this extract file to be the last in a series of extract files that will be used as input to a ROLLFORWARD.
Multiple output extract files from one archive journal
To create multiple extract files from one archive journal (one for each database segment, for instance) EXTRACT JOURNAL must be run multiple times, once for each group of database areas or files that you may wish to recover separately.
Since ROLLFORWARD has the ability to select images from an input extract file by area or file, you do not need an extract file for each area or file. For example, you can create an extract file for each critical database segment, and if a recovery is needed for one file in that segment, you can use ROLLFORWARD to recover just that file from the segment extract file. This speeds recovery while minimizing the number of extract tapes you need to maintain.
KSDS native VSAM records
EXTRACT JOURNAL does not support KSDS native VSAM records.
Controlling the starting point of the extract operation
If no START AT parameter is specified, the extract operation starts with the first journal image on the input archive file(s). If START AT is specified, the extract operation starts with the first checkpoint record (BGIN, COMT, ENDJ, ABRT, or CKPT) whose timestamp is on or after the specified 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 extract operation to begin processing at a quiesce point that does not correspond with a journal file boundary.
If START AT is specified, quiesce point verification is always performed even if VERIFY QUIESCE NONE is specified. Limited verification will be performed unless full verification is specifically requested.
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 extract journal utility provides three levels of quiesce point verification: none, limited, and full.
None means that no quiesce point verification is performed. It is appropriate for extract operations whose input is not expected to coincide with a quiesce point. For example, if extracting journal information incrementally, then quiesce point verification could be used when processing the archive files produced immediately after a quiesce operation, but must not be used when processing subsequent archive files.
The limited and full options both enable quiesce point verification. They do this by checking for the existence of spanned recovery units that are recovery units that are active at the start of the extract 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 extract operation is not starting at a quiesce point. If this situation is detected and either limited or full quiesce point verification is in effect, the extract 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 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 extract operation might 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 extract 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 resulting extract file must not be used for recovery purposes. You must locate a quiesce point corresponding to a backup of the specified portion of the database and begin the extract operation from that point.
When to use full or limited verification
Full quiesce point verification should only be used if you expect that no indoubt spanned recovery units are active at the starting point of the extract operation. The only way to guarantee this is to process the 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 shut down 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 for which the extract is being performed. One way to do this is to use the DCMT QUIESCE SEGMENT command to quiesce a segment and then use the limited quiesce point verification when extracting records for that segment.
EXTRACT JOURNAL and Distributed Transactions
EXTRACT JOURNAL reports on distributed transactions and supports the use of an input manual recovery control file. The control file is used to complete InDoubt distributed transactions unless ALL is specified. For more information, see JCL Considerations as well as Common Facilities for Distributed Transactions.
Note: For considerations associated with distributed transactions during recovery operations, see the CA IDMS Database Administration Guide
|
Copyright © 2014 CA.
All rights reserved.
|
|