RE: SQL performance with Local journalling

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

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