Journal management and system performance

 

Journal management prevents transactions from being lost if your system ends abnormally or has to be recovered. Journal management writes changes to journaled objects immediately to the journal receiver in auxiliary storage. Journaling increases the disk activity on your system and can have a noticeable affect on system performance.

Journaling also increases the overhead associated with opening objects and closing objects, so as the number of objects you are journaling increases, the general performance of the system can be slower. The time it takes to perform an IPL on your system or vary on of an independent auxiliary storage pool (ASP) can also increase, particularly if your system or independent ASP ends abnormally.

The system takes measures to minimize the performance effect of using journaling features. For example, the system packages before-images and after-images, and any access path changes for a record in a single write operation to auxiliary storage. Therefore, journaling access paths, and before-images and after-images, usually does not cause additional performance overhead. However, they do add to the auxiliary storage requirements for journaling.

The system also spreads journal receivers across multiple disk units to improve performance. If you do not specify a maximum receiver-size option, then the system can place the journal receiver on up to ten disk units in a disk pool. If you specify a maximum receiver-size option, and a matching sufficiently large journal size threshold then the system can place the journal receiver on up to 100 disk units in a disk pool.

You can take measures to minimize the effect of journaling on your system performance:

• Consider using journal caching. Journal caching is a separately chargeable feature that causes the system to write journal entries to memory in large groups. When there are several journal entries in memory then the system writes journal entries from memory to disk. If the application performs a large number of changes, this can result in fewer synchronous disk writes resulting in improved performance. However, when you use journal caching, a few of the most recent updates to your journaled objects may be lost on an abnormal IPL or independent ASP vary on.

• Before using journal standby state, consider the potential System Managed Access Path Protection (SMAPP) impacts of making that choice and consider specifying INCACCPTH(*ELIGIBLE) on the Change Recovery for Access Paths (CHGRCYAP) command.

• Do not set the force-write ratio (FRCRATIO) parameter for physical files that you are journaling. You can let the system manage when to write records for the physical file to disk because the journal receiver has a force-write ratio of 1.

• Isolate journal receivers in a disk pool that is not the system disk pool, if the separate disk pool has at least two disk arms. This reduces contention when accessing the disks. If the separate disk pool does not have at least two disk arms, there is no performance benefit. For optimal performance, ensure that your I/O processors have adequate write cache. Performance can be better if the disk units in the disk pool are protected through device parity protection rather than mirrored.

• Consider using record blocking when a program processes a journaled file sequentially (SEQONLY(*YES)). When you add or insert records to the file, the records are not written to the journal receiver until the block is filled. You can specify record blocking with the Override with Database File (OVRDBF) command or in some high-level language programs. If you use the OVRDBF command, do the following:

  • Set the SEQONLY parameter to (*YES).

  • Use a large enough value for the NBRRCDS parameter to make the buffer approach the optimal size of 128KB.

• Consider minimizing the fixed-length portion of the journal entry using RCVSIZOPT(*MINFIXLEN) for the journal. When you specify this option, all of the data that is selectable by the FIXLENDTA parameter is not deposited. Therefore, that information does not have to be retrieved, benefiting journal performance.

• Consider omitting information from the journal entry you do not need using the OMTJRNE parameter. When you specify the OMTJRNE parameter for database physical files you will not deposit the file open and close entries which saves processing as well as disk storage space. Similarly, if you specify the OMTJRNE parameter for directories and stream files, the object open, close, and force entries are not deposited.

• Ensure you have enough write cache for your I/O processor (IOP).

 

Parent topic:

Journal management concepts

Related concepts
Receiver size options for journals Journal cache Frequently asked questions about journaling and disk arm usage Performance Disk management Striving for Optimal Journal Performance on DB2 Universal Database for iSeries Factors that affect remote journal performance

Related reference
Override with Database File (OVRDBF) command