Changing the state of local journals
Local journals can be in one of two states, active or standby. When the journal state of a local journal is active, journal entries are allowed to be deposited to the journal receiver.
Journal standby state is a separately purchased feature that prevents most journal entries from being deposited into the journal. Standby state is enabled by option 42 of the i5/OS® operating system. You can start or end journaling objects while the journal is in standby. However, when a journal is in standby state, you cannot use explicit commitment control. Also, records within database files that have referential integrity constraints cannot be modified, when the underlying journal is in standby state unless RESTRICT is specified on the ON UPDATE or ON DELETE attribute for the constraint. Additionally, records within database files that have data links defined cannot be modified when the underlying journal is in standby state.
An example of when you might want to put a journal into standby state is if the journal is on a backup system and you want the replicated copies of your objects on that system to incur very low overhead until role swap time. By having the journal in standby state until role swap time, a switchover to the target system can be accomplished more quickly because all objects on the backup system can remain journaled thus allowing the switchover processing to skip the costly step of starting journaling for all objects. Until the journal leaves standby state and reverts to active state the backup system is not incurring the overhead of journaling because most journal entries are not deposited when the journal is in standby state.
If there is an attempt to deposit a journal entry when the journal is in standby state, no entry is deposited, nor are any error messages sent to the application. In order to flag the transitions in and out of standby state, journal codes 'J' and entry types 'SI' and 'SX' are deposited when the local journal is put into and out of standby. Even though the journal state is standby, and most journal entries are not deposited, there are a few critical journal entries that will be deposited in a journal. Use the Journal entry information finder to see if a journal entry is still deposited even though the journal is in standby state.
Additionally, when a journal is in standby state the system elects not to provide System-Managed Access-Path Protection (SMAPP) for any access paths built over files journaled to the journal and flags the access paths as not eligible for SMAPP protection. These access paths remain not eligible until the underlying journal leaves standby state and reverts to active state. Because the access paths are not eligible for protection, in some select instances system performance may be negatively impacted when a journal is changed to standby state, This would most likely occur if the access paths are large and are actively being changed. Under those conditions the underlying SMAPP mechanism attempts to compensate by enabling SMAPP protection for multiple small access paths whose keys are changing and whose underlying physical files are not associated with journals in standby state.
Also, abnormal IPL duration or the vary on of an independent Auxiliary Storage Pool (ASP) duration may be affected if standby state is chosen because some access paths that are no longer eligible for protection may need to be rebuilt.
If performance degrades after switching to standby state, then some investigation should be done to determine if standby state is a primary contributing factor. To reduce any potential performance impact, INCACCPTH(*ELIGIBLE) can be specified on the Change Recovery for Access Paths (CHGRCYAP) command. Specifying INCACCPTH(*ELIGIBLE) will reduce potential overhead but will expose you to a potentially longer IPL or vary on of an independent ASP. As with many other options, deciding to use standby state is a trade off between run time performance and IPL or independent ASP vary on duration.
To ensure that switching to standby state is not causing undo IPL or independent ASP vary on concerns, use the Display Recovery for Access paths (DSPRCYAP) command periodically to display the estimated access path recovery time. If this value is much larger than the target access path recovery time and the total not eligible recovery time is greater than zero, then use F13 (Display Not Eligible Access Paths) to display a list of the not eligible access paths. This will identify the access paths not eligible for SMAPP protection along with a reason for their not eligible status. If the access paths with the highest estimated rebuild times are not eligible due to standby, then you may wish to reconsider your standby choice. In lieu of standby, you may want to consider journal caching, which often provides nearly as much performance relief.
When a local journal is created, the journal state of that journal is *ACTIVE. This means that journal entries can be deposited to the local journal. If a local journal is in standby state, journal entries with journal code 'J' and entry type 'LA' are deposited when the local journal is activated.
If a local journal has been put in standby state, activate it by doing the following:
- In the iSeries Navigator window, expand the system you want to use.
- Expand Databases.
- Expand the database you want to work with and Schemas.
- Click the Schema that contains the journal you want to activate.
- Right-click the journal, and select Properties.
- On the Journal Properties dialog box select Activate journal.
You can also use the Change Journal State (QjoChangeJournalState) API or Change Journal (CHGJRN) command to activate the local journal.
Parent topic:
Managing journalsRelated concepts
iSeries Navigator versus the character-based interface for journaling objects File identifier considerations for working with integrated file system entriesRelated reference
Change Journal State (QjoChangeJournalState) API Change Journal (CHGJRN) commandRelated information
Journal entry information finder