RE: finding sql request from download

SQE Plan Cache holds any statement still in the cache. Chances are it's
still in there, so that's a good place to look. From there you can use
Visual Explain to see why it's running so poorly.
If it's not executed by SQE, but rather CQE, then you can use Navigator's
SQL Performance Monitor (aka database monitor) to capture and analyze it.

As for our tools, there are 3 ways you can attack this type of problem:
- find, tune and optimize the workload (i.e. 'bad boy' SQL statement)
- throttle down this user's resource consumption when running this type of
workload, to ensure he doesn't monopolize the box while running it.
- audit and/or prevent this user from running this type of workload at
critical times of the business day

Hth, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com

-----Original Message-----
Subject: Re: finding sql request from download

Jim

The newest release might let you find the statement, as it is probably
in a system-wide statement cache - I've not used it yet, so maybe Elvis
or Birgitta or someone can point the way. Ops Nav has Visual Explain,
which can work with these things, I think.

Earlier releases, you'd have to run the database monitor - you have to
know the job - or else run it for everything - STRDBMON does the trick
on the iSeries, and there are monitors you can start in Ops Nav.

I suppose you could also have an exit program for QZDASOINIT and the SQL
stuff to filter out what happens, even control the priority. I believe
Elvis' company has such a product for just this kind of thing - check
out www.centerfieldtechnology.com

HTH
Vern