Example: Recover 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 you must perform an apply or a remove journaled changes operation.

Another reason that an object can have partial transactions is if a long-running rollback was forced to end. However, if an object has partial transactions because of a long-running rollback, you cannot recover it with an apply or remove journaled changes operation.

If you perform save-while-active operations that can result in objects that are saved with partial transaction, it is recommended that you use Backup, Recovery, and Media Services (BRMS). You can use BRMS to automate your backup and recovery operations. BRMS automatically applies changes to objects with partial transactions and restores them to a usable state. For more detailed information see the BRMS topic.

Note: By using the code examples, you agree to the terms of the Code license and disclaimer information.
Related concepts
Benefits of journal management
Journal management with the save-while-active function
Automatic deletion of journal receivers
Change journaling attributes of journaled objects without ending journaling
Keep track of journal receiver chains
Save journals and journal receivers
BRMS topic

Required journal receivers

When you recover objects with partial transactions, all of the journal receivers that are required for the recovery operation must be on the system. The recovery operation might require more journal receivers than just the last one you detached. The system looks for the last journal receiver with an journal entry for the object that indicates one of the following:

  • The last regular save.
  • The last save-while-active in which the object was saved without any partial transactions.
  • The earliest SC (start commit) entry for any open transactions that affect the saved object for a save with partial transactions.

The following illustration demonstrates these requirements.

  1. Starting with receiver MYRCV05 the apply journaled changes operation starts.
  2. The systems finds the SS entry that indicates the object was saved with partial transactions.
  3. If journal receiver MYRCV05 has the CM entry that indicates the transaction for the object was committed, the apply journaled changes operation applies the changes.
  4. If journal receiver MYRCV05 does not have the CM entry, the system looks back to previous journal receivers.
  5. Since the SC entry is not in MYRCV04, the system looks in MYRCV03.
  6. The system finds the SC entry in MYRCV03 and the transaction is rolled back to that point.

This figure illustrates that even though you are performing an apply journaled changes operation, it is still possible that the transaction can be rolled back and you will need previous journal receivers.

As the previous figure shows, even if you are performing an apply journaled changes operation, it is still possible that the transaction can be rolled back and you will need previous journal receivers.

Restore examples

All of the objects in the following examples are database files. The following are examples of recovering objects in a partial state from three possible scenarios:

  • Restore of a single object with partial transactions.
  • Restore of multiple objects with partial transactions resulting from a rollback that was forced to end.
  • Remove the partial transactions from an object that was restored with partial transactions.

Restore of a single object with partial transactions

In this example, an object, OBJ1 in library LIB1 was saved with a save-while-active operation while it had pending transactions. The save-while-active operation is the object's most recent save. Journaled changes start from the last save and end at the last sequence number in the journal receiver.

The following is an example of the APYJRNCHG command. The default value for FROMENT is *LASTSAVE. The TOENT parameter uses the *LASTRST value to apply journaled changes up to the journal entry when the object was last restored.

       APYJRNCHG JRN(JRN1) FILE(LIB1/OBJ1)
                 FROMENT(*LASTSAVE) TOENT(*LASTRST)
                 RCVRNG(*LASTSAVE)

The following is an example of the RMVJRNCHG command. The following command removes the changes in journal JRN1 from the all the members of OBJ1:

RMVJRNCHG JRN(JRNA1) FILE(LIB1/OBJ1)
          FROMENT(*LASTSAVE) TOENT(*COMMITSTART)
          RCVRNG(*LASTSAVE)

Starting with the last save journal entry, only changes for journal entries for any partial transactions are removed, back to the start of the commit transaction.

Remove partial transaction status from an object with partial transactions

This example uses the Change Journal Object (CHGJRNOBJ) command because the journal receivers are not available to perform an apply or remove journaled changes operation. The Partial Transactions (PTLTNS) parameter allows the object to be used, but does not complete the transactions. The object, BRKNOBJ, still has changes caused by the partial transactions, but you are able to open the file.

Attention: Only use the following command as a last resort. You will lose data if you use this command. You should only use this command for the following reasons:
  • You have objects with partial transaction as a result of the termination of a long-running rollback and you have no saved version to restore.
  • You have objects with partial transactions as a result of a save-while-active operation, and the journal receivers required to apply or remove journaled changes have been lost, destroyed, or damaged beyond repair.
       CHGJRNOBJ OBJECT(LIB1/BRKNOBJ *FILE) PTLTNS(*ALWUSE)
Note: Read the Code example disclaimer for important legal information.