Journal management prevents transactions from being lost if your
system ends abnormally or has to be recovered. To do this, journal management
writes changes to journaled objects immediately to the journal receiver in
auxiliary storage. This 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.
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
can also increase, particularly if your system 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, in addition
to 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, 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, you sacrifice
single system recovery because the entries that are still in the cache might
be lost on an abnormal IPL.
- 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).