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.

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.

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:

As the 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.

Here is an example of restoring 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.

One way to restore OBJ1 is to use the Apply Journaled Changes (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)

Another way to restore OBJ1 is to use the Remove Journaled Changes (RMVJRNCHG) command. The command removes the changes in journal JRN1 from the all the members of OBJ1. 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.

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

Here is another example showing how to 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.

       CHGJRNOBJ OBJECT(LIB1/BRKNOBJ *FILE) PTLTNS(*ALWUSE)

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.

Parent topic:

Recovery of journaled objects