IBM Support

Applying Journaled Changes Using a Remote Journal Receiver

Troubleshooting


Problem

This document explains how you can use remote journals and apply the changes to a target system.

Resolving The Problem

This document explains how you can use remote journals and apply the changes to a target system.

Remote journaling provides a means of propagating duplicate journal receivers from one system to another. The normal use is for programs on the remote system to be able to replicate changes from the source system. It also provides a means to keep backup journal receivers on another system, which can be saved and restored back to the original system if needed for recovery purposes.

There is no capability provided for the APYJRNCHG or RMVJRNCHG commands on the target system. This is because a remote journal does not have any objects journaled to it; changes cannot be applied directly from a remote journal receiver to a journaled object on the target side in a remote journal environment. However, there is a method by which remote receivers can be associated with a local journal on the target system that has objects journaled to it and then have the changes directly applied. This document is an outline of that method.

This is accomplished by redirecting the local receivers on the source system to a different library on the target system. The remote receivers can then be saved from the redirected library on the target system and restored back to the target to the library with the original name used on the source. Here is how this can be done:

Complete the following priming steps (done only one time):

Note: It is assumed that the journal and journaled objects already exist on the source system.

1.Create a journal on the target system in the same library that it is on the source.
2.Create a library (or libraries) on the target system and save/restore the initial version of all journaled objects from the source to the target. The target now looks similar to the source in that all of the journaled objects, the journal, and a receiver are in the same named libraries as the source, and the objects are all journaled on the target.
3.Add a remote journal to the source journal and redirect the journal and the receivers to a new, redirected library on the target. This is done using the ADDRMTJRN command. Specify the redirected library on the TGTJRN and RMTRCVLIB parameters.
4.Use the CHGRMTJRN to activate the remote journal asynchronously. The receivers are now being constantly replicated to the target.
Periodic steps that are done as often as desired to keep the target and the source synchronized:
1.Save the remote receivers from the redirected library on the target system.
2.Restore the remote receivers back to the target, to the same named library as on the source.
3.Run the appropriate APYJRNCHG command to get the new journaled changed applied to the objects on the target.
The journaled objects, journal, and receiver directory are now identical on the target to that of the source except for an extra, original receiver that is currently attached on the target. This extra receiver is useful because it provides a record of all of the applies that have taken place on the target.

Using this method, the target objects are as current as the last apply. Even if the source fails, the receiver in the redirected library on the target should be up to date.

If there is not a need to be absolutely current on the target side or there are not persistent communications connections, remote journal can be activated when desired and the catch-up mode of remote journal will send over the latest changes. The connection can be ended, the save/restore performed, and local apply issued on the target as stated above.

Consideration for open commit cycles:

This process is not appropriate in an environment where commitment control is used. In particular, in an environment where an alter table may occur.

If an alter table exists in an open commit cycle at apply time, the alter table will be rolled back. This is true even if the open commit cycle is eventually committed. There is a reference to this in the help text for APYJRNCHG, "If pending database object level operations exist, they are either committed or rolled back, determined by looking ahead in the journal for that transaction's C/CM or C/RB journal entry. If no C/CM or C/RB journal entry is found, the changes are rolled back."

One way to avoid this scenario is to only apply journal changes for complete commit transactions. This can be enforced by doing a CHGJRN SEQOPT(*RESET). The journal sequence number can only be reset if there are no open commit cycles. Applying journaling entries through the last entry on a receiver before the sequence number was reset guarantees that the apply ends with no open commit transactions.

Reference: //www.iprodeveloper.com/article/databasesql/disaster-recovery-on-a-shoest…

Note: Assistance in setting up the remote journal environment and applying journaled changes is beyond the scope of Support Line. However, detailed assistance is available through a consulting agreement.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0"}]

Historical Number

29904232

Document Information

Modified date:
18 December 2019

UID

nas8N1016589