The performance implications from starting operating system level journaling on your System i and iSeries servers can be significant. You may have initiated system security auditing for every object on your system. There might be transaction level journaling on all physical files, data areas and data queues.
Regardless of the purpose for journaling - the impact on your application performance and hardware expenditures can be controlled. Any data replication implementation, whether for high availability purposes or for data warehousing needs, requires that you start journaling on your system at some level. Maybe journaling is used solely for security auditing purposes or was initiated years ago and hasn't been used since.
Use the 'Work with Journal (WRKJRN)' command with the '*ALL' parameters to identify and record a listing of all journals on your system. The 'Work with Journal Attributes (WRKJRNA)' command can then be used to access the detailed information and attributes for each of these journals. Once inside of this command, use the 'F15=Work with receiver directory' function key to display a listing of all journal receivers that are currently attached to this journal.
Monitoring DASD utilization of your journal receivers is one way that you can control the performance impact of journaling on your system. The 'Total size of receivers' on the top right of this screen in conjunction with the 'Attach Date' of the oldest receiver in the center of this screen can be used to determine whether some neglected journal receivers just need to be cleaned up. You can use the '4=Delete' option directly from this display to delete any of the detached journal receivers. The '8=Display attributes' option can be used to identify the 'Number of entries' and 'Size' for each receiver.
After cleaning up the unused receivers that have been accumulating on your system, it is important to implement an automated procedure for retaining receivers based on a pre-defined data retention. The 'Change Journal (CHGJRN)' command can be used to specify whether a journal is managed by the system or by you.
Does 'Remote Journaling' reduce the performance impact on the system?
It can help - but does not resolve the underlying performance issue. Many systems accumulate a massive number of journal receiver transactions on an hourly basis. Using remote journaling can improve the performance of getting these transactions over to another system. A way to more dramatically improve overall system performance is to focus on ways to reduce the number of transactions per hour. Less DASD utilization, less memory activity, less CPU usage and less network traffic all lead to better overall performance. This comes from less transactions being created back on the source system.
A detailed analysis of journal transactions can easily reduce the volume by at least 80 percent.
How can we possibly reduce the number of journal receiver transactions when we don't have control over the application software?
- Identify temporary work files that are being used out of permanent libraries. All objects in these libraries are now being journaled. Use the 'ENDJRNPF' command to stop unnecessary journaling of these temporary transactions.
- Find data queues and data areas that are used for temporary movement of data between jobs. They are being security audited every time data moves in and out of these objects. Use 'CHGOBJAUD OBJAUD(*NONE)' command to disable the creation of these transactions.
- Locate temporary files and folders on the Integrated File System (IFS) that are not needed for security auditing or for data replication purposes. Use the 'CHGAUD OBJAUD(*NONE)' command to discontinue generation of these unnecessary security auditing (QAUDJRN) transactions.
- Analyze excessive database updates on specific physical files to determine whether software application changes could significantly reduce the journaling volume. You may have a batch process that runs repeatedly throughout the day on your system that updates every record in one of your master files. A detailed analysis of these update transactions could determine that only a small percentage of the records should be updated. The application is changing the 'Last Activity Date/Time' on every record when it should only do this if other values on the transaction have changed.
These types of changes can be made without having a negative affect on security auditing or data replication. If you have the adopted authority changing on the same program 6 million times per day - something is wrong!
The initial installation of the Workload Performance Series software includes an automated configuration and scheduling of default data collectors. The Journal Optimizer data collector runs at 6:00 AM the morning after install. It is limited to a maximum run time of 1 hour and focuses on a detailed analysis of the system security audit journal (QAUDJRN).
This default data collector will not 
run again on your system until you customize its parameters and schedule it for additional runs. You can change the journal to be the name for any that exists on your system. The run time limit will also need to be changed to allow more time for a full data collection and a more complete analysis. It takes a significant amount of system resources for data replication software to process and analyze massive journal receiver transactions. This data collector will equally need sufficient time and resources. We recommend starting it on a Saturday morning and giving it all weekend if necessary to get through a single days transactions.
A high-level snapshot of all journals on your system is captured each time this data collector is run. This overview of all journals gives you a quick and easy picture of all receiver transactions on the system. The WRKJRN and WRKJRNA commands mentioned earlier do provide you with all of this information. The critical performance statistics are consolidated here onto a single display. Clean up old and unused journal receivers. Use the online data navigation to view the detailed analysis of the selected journal and find the information that you need to reduce transaction volume on an ongoing basis. You can view the count of transactions by job, user, object, program and transaction type.
Finding those unnecessary adopted authority changes that are responsible for 83 percent of all security audit transactions on your system is only a few key strokes away. Eliminating unnecessary transactions at the source will result in optimum system performance.