You could turn on the statement monitor and do a snapshot for dynamic
statements. It will tell you the number of times each SQL statement was
executed during the snapshot window, the total execution time, total CPU
time, etc. Then you could take the ones with high average times and do
explains on them.

But you need sysadmin authority to do the snapshots.

Well, yes. See 2.

Yep. You want to take a snapshot and read it. Any blaring performance
problems will generally be evident in the summary, the top 4 screenfuls
of info.

Classic performance problems would be evident from "High water mark for
connections", "Time database waited on locks" and "Deadlocks detected".
If you're getting high numbers for either of the first two, or any of
the third, your web app is probably causing DB2 performance issues.

Sometimes of course, a misconfigured DB2 server is the issue, such as
lack of indexing. For this, you should find the statement in the
"Dynamic SQL Snapshot Result" with the highest Total Execution Times.
Copy the statement text and load it into the DB2 control centre on any
server with a complete copy of the DB you're testing, and run a "Query
Plan" on it. If you can see any TSCANs, or any blaring loss of execution
time on a certain part of the statement, you should be able to either
index it, fix your code so that it never occurs, or if worst comes to
worst, set the table to volatile cardinality.

I don't follow you here, (2) may cover it.

Civilian_Target