Journal File Operations

This section discusses routine performed journal activities. Descriptions of the available journaling qualifiers appear later in this chapter.

Note that journal maintenance activities usually occur at the same time as the database backups.

Processing Journal Files

The MUPIP JOURNAL command initiates the processing of journal files. Use the following JOURNAL qualifiers to perform key processing activities.

/EXTRACT Transfers information from journal files into files formatted for processing by M routines.

/RECOVER Transfers information in the journal file(s) back into database file(s).

/SHOW Reports summary information about journal files.

/VERIFY Reports on journal integrity.

Unlike indexed database files, journal files have a sequential format. Therefore, a damaged journal provides valid information up to the point where damage first occurred and, in some cases, even beyond that point.

Recovering Damaged Database Files

The following two methods enable you to recover a database from a journal file:

  • Forward Recovery (roll forward)

  • Backward Recovery (roll back)

All journal files permit Forward Recovery. Only journal files created with MUPIP SET /JOURNAL=BEFORE_IMAGES support Backward Recovery.

Activate database recovery from a journal file using the MUPIP JOURNAL /RECOVER command; with the /FORWARD qualifier for forward recovery, or with the /BACKWARD qualifier for backward recovery. If something, such as head-disk interference destroys a portion of the database file, /FORWARD recovery must be used because JOURNAL /RECOVER /BACKWARD will have no valid starting point.

Forward Recovery

A Forward Recovery procedure restores a backup copy of the database, and applies the journal file to that database file. The starting point for both the database and corresponding journal files must be identical. The journal file contains copies of each database update. Forward Recovery reads the entire journal file from the beginning and updates the backup copy of the database. To stop journal processing before the physical end of the journal file, specify a journal ending time using the optional MUPIP JOURNAL /BEFORE= qualifier.

Use MUPIP BACKUP to ensure that the beginning of the journal file coincides exactly with the beginning of the recovered database.

Forward Recovery generally takes longer than Backward Recovery. However, if the current database is destroyed, you must use Forward Recovery. If a journal file was created using NOBEFORE_IMAGES, that journal permits only Forward Recovery.

Example of Forward Recovery:

Example: MUPIP JOURNAL /RECOVER

This shows a recovery after a system crash at 10:35 which processes the entire journal file forward.

By adding /BEFORE="- - 10:30" to the command, the recovery stops when processing encounters updates that originally occurred after 10:30.

Backward Recovery

Backward Recovery applies the journal file to the active database, moving backward from the end of the file. Backward Recovery uses "before-image" journaling. With before-image journaling, GT.M captures the database updates, as well as "snapshots" of portions of the database immediately prior to the change caused by the update. JOURNAL /RECOVER /BACKWARD works only if the production database is usable, and if the MUPIP SET command that created the journal file specified the BEFORE_IMAGES qualifier.

In effect, BEFORE_IMAGES creates "mini-backups" preceding each database update. Backward Recovery uses the mini-backups to restore the database as far back in time as specified by the qualifiers used with the MUPIP JOURNAL command, then it replays the database updates.

Using Backward Recovery with the MUPIP JOURNAL qualifiers /SINCE=, /BEFORE=, and /LOOKBACK_LIMIT=, you can specify a block of time to recover.

[Note]

"Before-image" journaling requires more disk I/O and storage space than M-level (or NOBEFORE) journaling.

Do not delete a database that you want to /BACKWARD recover. Recovery can only occur into an existing/used database.

Use /RECOVER /FORWARD for databases that have been recreated.

Example of Backward Recovery:

This shows a recovery after a system crash at 10:35. The recovery "un-does" the database updates backward to 10:20, then applies updates forward until the crash. By adding /BEFORE="- - 10:30" to the command, the recovery stops when forward processing encounters updates that originally occurred after 10:30. If the application includes ZTSTART and ZTCOMMIT commands to fence a group of transactions, backward processing may continue back prior to 10:10 searching to resolve fenced transactions that were incomplete at 10:20. The /LOOKBACK_LIMIT= qualifier controls the maximum amount of additional backward processing, in this case, 10 minutes. Note that the /SINCE time in this example is slightly exaggerated for the sake of the graphical representation.

Recovering with Broken Transactions

In the case of a catastrophic event, it is unlikely that GT.M can properly complete writing all journal records to the file. MUPIP JOURNAL processing reports the unfinished records or incomplete fenced transactions as "broken transactions". The broken transactions are extracted into a file (the broken transaction file). Any complete transaction that occurred in time after a broken transaction is also not played into the database but instead extracted out as a lost transaction into a different file (the lost transaction file). The operational procedures and the application tools should provide a means of recovering and reprocessing the information in the broken and lost transaction files after a recovery or rollback that places content in these files.

The /ERROR_LIMIT= qualifier to MUPIP JOURNAL enables processing to continue. It attempts to skip over errors until the number of errors exceeds the specified limit. The /INTERACTIVE qualifier to MUPIP JOURNAL lets an operator control whether processing continues once the /ERROR_LIMIT= limit has been exhausted.

Processing After a Recovery

If you are using fences around logical transactions, initiate re-entry of any broken or lost transactions. If you are not using fences, repair any application-level integrity problems. In either case, MUPIP INTEG /FAST provides an excellent quick test of whether the database can support new updates with relative safety.