Planning which objects to journal

 

When you plan which objects to journal, consider the following:

• What types of objects you can journal.

• What makes an object a good candidate for journaling.

• What rules for journaling apply to those objects.

• Whether or not to send journal entries for objects the system does not journal.

 

Types of objects that are eligible for journaling

You can journal the following object types:

• Database physical files

• Access paths

• Data areas

• Data queues

• Integrated file system objects (stream files, directories, and symbolic links)

 

General characteristics that make objects good candidates for journaling

• An object with a high volume of transactions between save operations is a good candidate for journaling.

• An object that is difficult to reconstruct the changes made to it, such as an object that receives many changes without physical documentation. For example, an object used for telephone order entry is more difficult to reconstruct than an object used for orders that arrive in the mail on order forms.

• An object that contains critical information. For example, if you restore an object back to the last save operation, and the delay from reconstructing changes to that object has a negative effect on your operation: that object is a good candidate for journaling.

• Objects that relate to other objects on the system. Although the information in a particular object may not change often, that object may be critical to other, more dynamic objects on the system. For example, many files may depend on a customer master file. If you are reconstructing orders, the customer master file must include new customers or changes in credit limits.

• Objects that require that all the actions on it be replicated.

• An object, that, after a crash, has a requirement to be recovered to a consistent state and have a journal entry show what actions completed.

• An object that can cause a negative consequence to your operation if a crash damages that object while the system is in the process of updating it.

• An object for which you want to have an audit trail of changes.

Considerations for journaling database physical files

• If you journal one file that participates in a referential constraint, journal all the related files. Referential constraints are not enforced when you apply or remove journaled changes, but the referential integrity of those constraints is verified.

• If you journal all related files, the process for applying and removing journaled changes keeps the relationships between your database files valid. If you do not journal all related files, your referential constraint may show a status of check pending after you apply or remove journaled changes. For some types of referential constraints, the system requires that you journal all of the related files.

• For a file that has a trigger program, if the trigger program only performs processing on object types which can be journaled and applied, journal all of the objects processed by the trigger program. If the trigger programs do additional work that must be reconstructed during a recovery, consider using the API support for sending journal entries.

• In general, database source files must not be journaled. If you use the Start Source Entry Utility (STRSEU) command to update a member, every record in that member is considered changed and every record is journaled to the journal. However, if changes to a source file are critical, you can journal the file in the same manner as data files.

 

Considerations for journaling integrated file system objects

• When you start journaling on a symbolic link, the link is not followed. Therefore if you want to protect the actual object with journaling, you have to journal the actual object separately.

• If you want to automatically protect all objects which are created in a directory which itself is journaled, consider the use and impacts of the inherit journaling attribute that you can associate with a journaled directory.

• Do you want to protect the structure of the directory tree, or just the data stored in stream files within that directory structure? If you just want to protect the data stored in stream files, then for performances reasons, it may be best to only journal the stream files themselves instead of journaling changes to each directory in the directory tree. You must consider this question when you use the subtree and inherit journaling attributes options on the start journaling interfaces.

• You cannot journal objects on a user-defined file system (UDFS) independent disk pool. If you want to journal objects in a UDFS, use a library capable independent disk pool. Journal management and independent disk pools has more information about journaling and independent disk pools.

 

System objects

IBM recommends that you do not journal changes to IBM™-supplied objects. The system sometimes creates and manages these objects differently than user-created objects. The system does not assure the recovery of these files even though all recovery activity normally succeeds.

 

Journal entries for objects the system does not journal

Some applications depend on information in objects that the server does not journal. For example, an application programming interface (API) might use a user space to pass data between two jobs.

You can use the Send Journal Entry (SNDJRNE) command or the Send Journal Entry (QJOSJRNE) API to write journal entries for these resources. If you need to perform recovery, you can use a program to retrieve these journal entries and make sure these application objects are synchronized with the objects you are journaling.

If you are using commitment control, you can use APIs to register these objects as committable resources.

 

Before images and access paths

• Reasons to journal access paths has detailed information about whether or not to journal access paths.

• Reasons to journal before-images discusses whether or not to journal before-images

Journaled object limit

The journaled object limit is the maximum number of objects that can be journaled to one journal. You can set the journal object limit to either 250 000 or 10 000 000. Use the Journal Object Limit (JRNOBJLMT) parameter on the Create Journal (CRTJRN) or Change Journal (CHGJRN) command to set the maximum number of journaled objects.

 

Journal recovery count

On the CHGJRN command, you can use the Journal Recovery Count (JRNRCYCNT) parameter to indicate how many journal entries can exist between the last deposited entry and the oldest forced entry for a journaled object. A value between 10 000 and 2 000 000 000 will be allowed. A value of *SYSDFT will also be allowed to reset the journal’s recovery count to the system default journal recovery count.

• Reasons to journal access paths
  If you journal access paths, the system can use the journal entries to recover access paths instead of rebuilding them completely.

• Reasons to journal before-images
  When you journal an object, the system always writes an after-image for every change that is made. You can request that the system write before-image journal entries for database files and data areas. All other object types only journal after-images. This significantly increases the auxiliary storage requirements for journaling.

 

Parent topic:

Planning for journal management

Related concepts
Journal management and independent disk pools Sending your own journal entries Commitment control JKLPROD JKLDEV

Related reference
Work with triggers and contraints