Confirmed and unconfirmed journal entries

 

For a local journal, all entries are confirmed entries. There is no concept of unconfirmed entries.

For a remote journal that is maintained asynchronously, all entries are confirmed entries. For a remote journal that is maintained synchronously, there are both confirmed and unconfirmed entries. Unconfirmed entries will only become important if you are using the remote journal support for a hot-backup or data replication environment, and the source system has a failure such that the target system will take over processing.

Confirmed journal entries are journal entries replicated to a target system, and the state of the I/O to auxiliary storage for the same journal entries on the primary system is known to have completed.

Unconfirmed journal entries are entries replicated to a target system, but the state of the I/O to auxiliary storage for the same journal entries on the primary system is not known. Unconfirmed entries only pertain to remote journals that are maintained synchronously. The remote I/O to the remote journal is overlapped with the local I/O to the local journal for better performance. Such journal entries on the target system are held in the data portion of the journal receiver. However, the journal entries are not officially included with the remainder of the journal entries until the confirmation of the I/O for the same entries is received from the primary system. For performance reasons, confirmation of these entries is not typically sent to the target system until some later delivery of journal data to the target system.

While the journal entries are unconfirmed on a target system, the entries typically cannot be retrieved from the remote journal. You can retrieve the journal entries by using the INCENT(*ALL) parameter on the following commands:

You can also retrieve the journal entries by specifying *ALL for the include entries key for the Retrieve Journal Entries (QjoRetrieveJournalEntries) API. The INCENT(*ALL) parameter, or include entries key specification of *ALL, requests that all confirmed and unconfirmed entries are included. This means that for synchronous remote journal function, the last few journal entries are not immediately retrievable from the remote journal by using the default command invocations. This is true even though all journal entries physically reside in both the local journal and the remote journal. This is done so that application programs do not make decisions on the target system by using journal entries that may not end up being deposited into the local journal. This is because those journal entries would not cause a change to the original data.

With respect to a hot-backup application apply, in most circumstances only the confirmed journal entries in the remote journal are of interest. In the data replication environment, a hot-backup application apply would probably never want to apply any unconfirmed journal changes. This is because any subsequent activation of the remote journal will ensure that the journal entries in the remote journal will match the journal entries in the source journal. However, as described in Scenario: Recovery for remote journaling, knowledge of the unconfirmed journal entries is essential during the switch-over and switch-back processing for a hot-backup environment.

When a remote journal is inactivated, all unconfirmed entries are removed from the remote journal. It is important that those entries are retrieved prior to the remote journal being inactivated, if those entries are desired for additional processing on the backup system. The message that is sent to the journal message queue when the remote journal is inactivated by the system will indicate if the remote journal has any unconfirmed journal entries.

 

Parent topic:

Getting information about remote journal entries

Related concepts
Journal state and delivery mode Synchronous and asynchronous delivery mode for remote journals Working with remote journal error messages

Related reference
Retrieve Journal Entries (QjoRetrieveJournalEntries) API
Related information
Scenario: Recovery for remote journaling