Re: Journal performance problems -- MIDRANGE-L

There's a little-known solution - turn on commitment control. Without this, jobs can take 3-4 times as long to finish. Here's an extract from an article by Rick Turner:

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.

There's more in the article, including side effects of SMAPP on journaling performance, available at <http://www-1.ibm.com/support/docview.wss?uid=nas1e907e76673a614dd86256a290054f546&rs=110>

HTH

Vern

At 11:32 AM 5/1/2003 +0200, you wrote:

Hello,

well, we are currently setting up our HA solution (DataMirror).
Therefore, we had to start journalling on all production files.

The journals are located in ASP2, which has 1 (mirrored) disk drive with
about 17.5GB capacity (type 6718).

We now find we have severe performance problems some times. There's an
invoicing job that normally runs about 1:30 hours and now takes 2:30 w/o
much change in database activity. The only other active batch job at that
time is also database intensive and runs longer than normally.

My guess is these jobs are waiting for journal entries to be written. The
ASP2 disk drive is very busy at that time.

Any ideas on how to confirm this?

Also, we could add a disk drive to ASP2, which should help some. Or might
it be better to cancel ASP2 and add the disks to ASP1?

I've started Management Central performance monitoring to get a better
look at system activity.

Any suggestions?

Regards,

Oliver