Journaling for Performance

Journaling for Performance
For many AS/400 users, database journaling is essential for a proper system backup. Properly configured, the system’s journaling functions can provide reliable high-availability information and optimized performance.
Database information is written to a journal receiver. The system’s journaling functions "spread" a journal receiver across numerous disk arms. The system blocks and writes data to the journal receiver using a "round robin" approach; each journal data record is written to a different disk arm than the one used for the preceding journal receiver records. If the journal receivers are in their own disk auxiliary storage pool (ASP) and only one journal receiver is active at a time, this approach ensures that that no arm contention occurs when multiple concurrent journal writes are in progress.
The steps for achieving optimal journal performance include:
1. Put the journal receivers in their own distinct disk ASP.
2. Have only one active journal receiver in the ASP at a time.
3. Use mirroring instead of RAID to protect the journal ASP devices.
When a journal receiver is the only active object in a separate ASP, there’s minimal disk arm contention. Most often, the disk arm doesn’t have to be moved at the start of an I/O operation; it can be moved when a cylinder is full. However, if multiple active journal receivers are in an ASP, or the journal receiver is in the system ASP along with production database files, there’s a high probability of arm contention. Each journal write will probably require arm movement (e.g., a seek) before performing the write.
If the journal receivers are in a RAID-protected ASP, each journal write must perform four disk I/O operations to perform the RAID function. For each write from the CPU, there are two reads and two writes at the device and IOP level. In an environment with a lot of write operations (e.g., a batch environment), this can significantly increase the runtime.
On a RAID-protected device, the data exists on the outside (growing inward) and the RAID stripes are on the inside (growing outward). So if you write your journal record to a RAID-protected device, the device must seek to the outer edge, perform the I/O, and then seek to the inner edge to read the RAID information. This can really slow a high-performance journal receiver device.

Commitment Control & Journaling
Though most database and other write operations are asynchronous, database journal receiver write operations are usually synchronous to the issuing job. This means the job is forced to wait (in the system’s disk I/O write functions) for the I/O (write) to complete before it continues processing. The SLIC Journal functions can do the journal writes asynchronously if the job uses commitment control.
When commitment control is in effect, the database journal write functions know that file integrity is required only at a commit boundary and not at every record update/add/delete operation. Because of this, the database journal writes are scheduled asynchronously. When a commit boundary is reached, the database functions ensure that all pending database file I/O is complete before continuing.
Lab tests show that using commitment control and journaling yields performance almost equal to not using database journaling. If you use journaling but not commitment control, a job can be three to four times slower than when you don’t use journaling at all.
"But this means I have to change my code!" you say. True, but the cost of the changes are minimal compared to the performance benefit. In the CL program that calls the batch program, specify the files that use commitment control and open them. Start a commit cycle in the CL program before calling the batch program. In the application program(s), change the file description to specify that commitment control is in use. Once the program returns to the CL program, end the commit cycle to force any pending file I/O to complete.