RE: SQL performance with Local journalling -- MIDRANGE-L

I would use SETOBJACC *PURGE on the file in question between the runs. But the issue is probably high I/O - without journal caching, every (probably) change in a PF is also written to disk, using more I/O. Just turning on commitment control, I'm told, turns on some journal caching. If all you want is to improve the performance, you don't need to actually do commits/rollbacks. In this case, I think I'd set lock level to *CS, to avoid long locks - check the help for STRCMTCTL.

This information is based on my recollection of what I was told by one of the folks who worked on journaling at IBM, as well as the journal cache parameter on CRTJRN. I hope my memory is good - try it out.

Vern

At 04:49 AM 2/24/2005, you wrote:

Hi Eric,
that's why I got them to run it the other way round - i.e. with journalling on first - to try and eliminate this factor. Is there something else I should be thinking.
Regards
Evan Harris
At 08:55 a.m. 24/02/2005, you wrote:
Maybe they need to purge the file from storage...
When they turned journaling off and reran the query, the object was already
paged into a storage pool, giving the illusion of exceptional performance.
Use the CLRPOOL command before each run...
hth,
Eric DeLong

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.