The following qualifiers control journal processing:
-[NO]AP[PLY_AFTER_IMAGE]
Specifies that after image records (AIMG) be applied to the database as part of forward processing of backward recovery or rollback. AIMG are "snapshots" of the database updates captured by GTM immediately after the change caused by a DSE update. By default, during forward phase of backward recovery or rollback, AIMG records are applied to the database.
By default, -RECOVER -FORWARD does not apply AIMG record into the database. -APPLY_AFTER_IMAGE is compatible with -RECOVER, or -ROLLBACK action qualifiers only.
-BR[OKENTRANS]=<extract file>
-BROKENTRANS is an optional qualifier for -ROLLBACK, -RECOVER and -EXTRACT. If this is not specified and a broken transaction file creation is necessary, MUPIP JOURNAL creates one using the name of the current journal file being processed with a .broken extension.
Note that, if selection qualifiers are specified, the broken transaction determination (and therefore lost transaction determination as well) is done based on the journal file that is filtered by the selection qualifiers. This means that a transaction’s journal records may be considered complete or broken or lost, depending on the nature of the selection qualifiers. Using -FENCES=NONE along with the selection qualifiers will result in every journal record to be considered complete and hence prevent broken or lost transaction processing.
-[NO]CHA[IN]
-CHAIN allows JOURNAL processing to include previous generations of journal files with -FORWARD. If JOURNAL -RECOVER needs to process previous generation journal file(s) and -NOCHAIN is specified, MUPIP JOURNAL exits with an error.
-CHAIN is the default.
-[NO]CHE[CKTN]
-CHECKTN specifies that JOURNAL -FORWARD must verify for each region that the begin transaction number of the earliest journal file to be processed for that region is same as the current transaction in the database file and that the end transaction number of every journal file is equal to the the begin transaction number of the next generation journal file for a given region. By default, -FORWARD uses -CHECKTN.
-NOCHECKTN forces forward recovery by overriding inbuilt mechanisms for checking transaction integrity. Use -NOCHECKTN with caution because it may lead to integrity issues in the recovered database and journal files.
-CHECKTN is incompatible with -BACKWARD and -ROLLBACK.
-[NO]ER[ROR_LIMIT][=integer]
Specifies the number of errors that MUPIP JOURNAL processing accepts. When the number of errors exceeds the -ERROR_LIMIT, the -INTERACTIVE qualifier determines whether JOURNAL processing halts or defers to the operator. -NOERROR_LIMIT prevents MUPIP JOURNAL from stopping because of errors. Journal processing continues until it reaches the end of the journal file, regardless of the number of errors.
Note that, -NOERROR_LIMIT is not the same as -ERROR_LIMIT=0.
By default, MUPIP JOURNAL uses -ERROR_LIMIT=0, causing the first error to initiate the appropriate error action. In case of a crash there could be some incomplete journal records at the end of a journal file. MUPIP JOURNAL does not consider these as errors. In addition, fenced transactions that are broken are not considered as errors.
During the forward phase of recovery, if a broken transaction is found, all the logical records processed afterwards are considered suspect. If a complete transaction is found after any broken transactions, MUPIP JOURNAL -RECOVER increments the error count and, if it is less than the error limit, it is applied to the database. Otherwise, it is treated as a lost transaction and extracted. If a complete transaction is found after any broken transactions, MUPIP JOURNAL -ROLLBACK treats it as a lost transaction and extracts it irrespective of the error limit.
If MUPIP JOURNAL needs to increment error count during its processing, a warning message is issued for every error encountered except in the following cases when the error count is incremented but no warning message is displayed:
When a complete transaction is found after a broken transaction
When -EXTRACT -FULL encounters errors
If MUPIP JOURNAL completes successfully with a non-zero value of error count, the return status is not a success, but a warning.
-FE[NCES][=fence-option]
Specifies how JOURNAL processes fenced transactions. Fenced transactions are logical transactions made up of database updates preceded by a TSTART or ZTSTART command and followed, respectively, by a TCOMMIT or ZTCOMMIT command. All updates between a TSTART or ZTSTART and a TCOMMIT or ZTCOMMIT are designed to occur together so that after journal recovery the database contains either all the updates corresponding to a fenced transaction, or none of them.
The argument values for -FENCES option for MUPIP -RECOVER are not case-sensitive.
The fence options are:
NONE
This causes MUPIP JOURNAL to apply all individual updates as if transaction fences did not exist. Note that, this means a SET/KILL within a TP or ZTP transaction would be played as if it was an unfenced SET/KILL. This may cause the database and new journals created (if -BACKWARD is specified), to be different from the state before the recovery took place.
ALWAYS
This causes MUPIP JOURNAL to treat any unfenced or improperly fenced updates as broken transactions.
PROCESS
This causes MUPIP JOURNAL to accept unfenced database updates, and also to observe fences when they appear, generating broken transaction files in the case of a TSTART with no corresponding TCOMMIT, or a ZTSTART with no corresponding ZTCOMMIT. It also generates broken transactions if a multi-region transaction with TSTART and TCOMMIT expects N regions to participate, but the number of TSTART/TCOMMIT pairs found is less than N. The same happens for multi-region ZTSTART and ZTCOMMIT.
By default, MUPIP JOURNAL uses -FENCES=PROCESS.
-FU[LL]
-FULL when used with -EXTRACT, specifies that all journal records be extracted. A journal file's contents can be rolled back in case of backward recovery or rollback (refer to “-REC[OVER] ” or “-ROLLBACK ” for more details) in order to keep the database and journal in sync. This is achieved not by truncating the contents of the journal file but instead setting a field in the journal file header, which shows up as "Prev Recovery End of Data" in a MUPIP JOURNAL -SHOW=HEADER output, to indicate the end of the journal file before rolling back and setting another field in the file header to indicate the new end of the journal file (this field shows up as "End of Data" in a MUPIP JOURNAL -SHOW=HEADER output). Once a journal file's contents are rolled back, all future MUPIP JOURNAL commands (including -EXTRACT) operate on the rolled back journal file only. But if -FULL is specified along with -EXTRACT, the entire journal file contents (including those records that were rolled back) are extracted. This qualifier is to be used only as a diagnostic tool and not in normal operation.
-FULL qualifier is compatible with -EXTRACT only.
-[NO]IN[TERACTIVE]
Specifies whether, for each error over the -ERROR_LIMIT, JOURNAL processing prompts the invoking operator for a response to control continuation of processing. If the operator responds that processing should not continue, the MUPIP JOURNAL command terminates.
-NOINTERACTIVE terminates the journal processing as soon as the MUPIP JOURNAL command generates the number of errors specified in -ERROR_LIMIT.
This qualifier is applicable only to interactive mode or terminal mode. The default is -INTERACTIVE.
-LOST[TRANS]=<extract file>
-LOSTTRANS is an optional qualifier for -RECOVER, -ROLLBACK and -EXTRACT. If this is not specified and a lost transaction file creation is necessary, MUPIP JOURNAL creates one using the name of the current journal file being processed with a .lost extension.
Any complete transactions after a broken transaction is considered a lost transaction. They are written into the lost transaction file. For -RECOVER it might be considered as good transaction and applied to the database, if -ERROR_LIMIT qualifier allows it to do so.
Note that, if selection qualifiers are specified, the broken transaction determination (and therefore lost transaction determination as well) is done based on the journal file that is filtered by the selection qualifiers. This means that a transaction’s journal records may be considered complete or broken or lost, depending on the nature of the selection qualifiers. Using -FENCES=NONE along with the selection qualifiers will result in every journal record to be considered complete and hence prevent broken or lost transaction processing.
In the case of a replicated database, lost transaction can have an additional cause. If failover occurs (that is, the originating Source Server, A, fails and the replicating Source Server, B, assumes the originating instance's role), some transactions committed to A's database may not be reflected in B's database. Before the former originating instance becomes the new replicating instance, these transactions must be rolled back. These transactions are known as "lost transactions". Note that these are complete transactions and different from a broken transaction. MUPIP JOURNAL -ROLLBACK stores extracted lost transactions in the extract-file specified by this qualifier. The starting point for the search for lost transactions is the journal sequence number obtained from the originating Source Server in the -FETCHRESYNC operation.
-RED[IRECT]=file-pair-list
Replays the journal file to a database different than the one for which it was created. Use -REDIRECT to create or maintain databases for training or testing.
This qualifier applies to -RECOVER action and -FORWARD direction qualifier only. JOURNAL rejects -REDIRECT unless it appears with -RECOVER.
The file-pair-list consists of one or more pairs of file-names enclosed in parentheses () and separated by commas (,). The pairs are separated by an equal sign in the form:
old-file-name=new-file-name
where the old file-name identifies the original database file and the new file-specification file-name identifies the target of the -RECOVER. The old-file-specification can always be determined using -SHOW.
By default, JOURNAL directs -RECOVER to the database file from which the journal was made. -REDIRECT is not compatible with -ROLLBACK.
Example:
$ mupip journal -recover -forward -redirect="bgdbb.dat=test.dat" bgdbb.mjl
This JOURNAL command does a forward recovery that -REDIRECTs the updates in bgdbb.mjl from bgdbb.dat to test.dat.
-VERB[OSE]
Prints verbose output in the course of processing. It is not negatable and it is set to OFF by default.