Recovery of journaled objects

 

One of the primary advantages of journaling is its ability to return a journaled object to its current state since the last save.

You can recover from many types of damage to journaled objects by using journaled changes. For example, an object is damaged and becomes unusable, an error in an application program caused records to be improperly updated, or incorrect data was used to update an object. In each of these instances, only restoring a saved version of the object can result in the loss of a significant amount of data.

If you use the Apply Journaled Changes (APYJRNCHG) or Apply Journaled Changes Extend (APYJRNCHGX) command to apply journaled changes, significantly less data may be lost. You can use the Remove Journaled Changes (RMVJRNCHG) command to recover from improperly updated records or incorrect data if before-images have been journaled. This command removes (or backs out) changes that were made to an object.

Use the APYJRNCHG command to apply changes to these object types:

• Database file

• Integrated file system object

• Data area

• Data queue

Use the APYJRNCHGX command to apply changes to database files.

Use the RMVJRNCHG command to remove changes that were made to these object types:

• Database file

• Data area

To recover an object by applying or removing journaled changes, the object must be currently journaled. The journal entries must have the same journal identifier (JID) as the object. To ensure the journal identifiers are the same, save the object immediately after journaling is started for the object.

To apply or remove journaled changes to or from a restored copy of the object, have already saved the object while it was being journaled. Why save objects after you start journaling has more information about saving journaled objects and about JIDs.

If you need to recover objects that were journaled to a journal that you deleted, restore the journal from a saved copy or create a new journal with the same name in the same library. Then restore the object and all the needed receivers before applying or removing journaled changes with that journal. You can use an option on the Work with Journals display to reassociate any journal receivers that are still on the system. To use the Work with Journals display, use the Work with Journals (WRKJRN) command.

Some types of entries in the journal receiver cause the apply or remove process to possibly stop. These entries are written by events that the system cannot reconstruct. Certain illogical conditions, such as a duplicate key in a database file defined as unique, can also cause processing to end.

Use the Object Error Option (OBJERROPT) of the APYJRNCHG, APYJRNCHGX, or RMVJRNCHG commands to determine how the system responds to an error. If you select OBJERROPT(*CONTINUE) and an error occurs, processing of journal entries stops only for the object associated with that error. Processing continues for the other objects. The system sends a diagnostic message indicating that the processing of journaled changes for that object was not successful. The system also places an indication that processing ended early for the specific object in any output file record. If you select OBJERROPT(*END), processing ends for all objects when an error occurs.

Using save-while-active to save your journaled objects can help you recover your objects more quickly when you need to apply or remove journaled changes specifying FROMENT(*LASTSAVE) or FROMENTLRG(*LASTSAVE). When you use the save-while-active function to save your journaled objects, the system saves and then restores information that indicates which starting journal sequence number is needed for the apply or remove operation. When this information is available for all objects to which you are applying or removing journaled changes, the system does not need to scan the journal receivers to determine this starting point. Scanning journal receiver data to find the starting points can be time consuming.

Also, using save-while-active when saving your objects allows you to restore a version of your object which was not from the last save and to still specify FROMENT(*LASTSAVE) or FROMENTLRG(*LASTSAVE) on the apply or remove command and successfully apply or remove changes.

Actions of applying or removing journaled changes by journal code shows how operations that apply and remove journaled changes handle journal entry types. It shows which entry types cause processing to end for an object and what processing is done when the entry is applied or removed.

You can use partial receivers to apply or remove changes from an object. If you attempt to restore a saved receiver while a more current version of the receiver is on the system, an escape message is sent to prevent you from restoring the receiver. The system makes sure that the most complete version is preserved.

You can use a partial receiver as the first receiver in the receiver chain for a RMVJRNCHG command only if you specify a sequence number for the FROMENT or FROMENTLRG parameter.

• Applying journaled changes
  If an object becomes damaged or is not usable you can recover the object using the Apply Journaled Changes (APYJRNCHG) or Apply Journaled Changes Extend (APYJRNCHGX) command. If you restore an object that was saved with partial transactions, then apply journaled changes to that object before it is usable.

• Removing journaled changes
  Depending on the type of damage to the journaled object and the amount of activity since the object was last saved, removing changes from the object can be easier than applying changes to the object. Use the Remove Journaled Changes (RMVJRNCHG) command to remove changes from an object if you are journaling before-images.

• Use of the QAJRNCHG file
  You can use the apply and remove journaled changes output (QAJRNCHG) file to make a record of all the activity that occurs when you perform an apply or remove journaled changes operation.

• Journaled changes with trigger programs
  The system does not call trigger programs when it is applying or removing journal entries.

• Journaled changes with referential constraints
  When you apply or remove journaled changes, journal management does not support referential constraints.

• Actions of applying or removing journaled changes by journal code
  The following table shows the actions that are taken by the Apply Journaled Changes (APYJRNCHG), Apply Journaled Changes Extend (APYJRNCHGX), or Remove Journaled Changes (RMVJRNCHG) command by journal code and entry type.

• When the system ends applying or removing journaled changes
  The system ends applying or removing journaled changes as a result from one of the following items:

• Example: Applying journaled changes
  This topic provides examples of the Apply Journaled Changes (APYJRNCHG) command applied to a database physical file, integrated file system object, data queues, and data area.

• Example: Removing journaled changes
  Even though the following examples show database physical files and data areas being processed separately, you can do them with one Remove Journaled Changes (RMVJRNCHG) command if you use the OBJ parameter for both object types.

• Example: Recovering objects with partial transactions
  If you restore an object that was saved with a save-while-active operation that specified that the object can be saved before it reaches a commitment boundary, it can have partial transactions. To recover objects that are in a partial state perform an apply or a remove journaled changes operation.

 

Parent topic:

Recovery operations for journal management

Related concepts
Why save objects after you start journaling Using SAVCHGOBJ to save journal receivers