Trying to prove one set of queries is killing performace (50% CPU)

Question

A set of queries for which SUM( cpu_time ) from the V$SQLAREA view represents around 50% of all CPU_TIME in the entire V$SQLAREA at any given point in time. We ran the check every 15 seconds and these queries always count for a hughe 40-60%.
QUESTION: given that pin ratio is 99+% for SQL AREA, can we assert that these few queries are actually responsible for +/- 50% of the load ?
This is important to us as we have a workaround that will be costly to put in place and want to confirm the hypothesis before undertaking the work. Moreover, thess queries are coming from an ERP and we may need their approval to do such customization.
We saw interesting stuff on the FORUM confirming our thinking but could not see anything yet that positively confirms our approach.
Thx a lot
Claude Huard

Answer 1

Thanks John,
This is a long story. We first looked at Statpack info. We are READ and CPU intense. We have then identified the TOP SQL, the so-called "bad guys". We regognize them by the table they access.
To see how bad the bad guys were, we have tried this V$SQLAREA thing I am questioning about and the numbers were impressive ( 40 - 65 % of CPU_TIME ).
Parallelly, we could also confirmed that when then BUFFER_GETS go higher than a certain threshold, the response time for a typical query running every 20 minutes is degradating. The two curves follow a similar pattern.
Tadam : we believe we have found the bad guys that most likely impact performance and make users complain.
Fixing the bad guys is an issue because they are in the core of a financial ERP so we need a good case to undertake that effort. We would also prefer having the vendor’s support in the customization effort.
To build our case, we though we could show the relative load of the bad guys with respect to the entire load. Back to the original question, maybe I shall nuance what I mean by the every-15-seconds lookup. We get the instant face value of the cumulative CPU_TIME (and BUFFER_GETS, etc.) for the cursors. One lookup is the sum of all cursors within V$SQLAREA. Another lookup is the sum of those bad guys matching a criteria (excluding our own query...). What we look at is the delta between two cumulative values. The sum of all cursors increases by such and the sum of the bad guys increases by such. That is the percentage of increase we are looking at. Does that approach make sense ?
Plese note that the cumulative for the entire V$SQLAREA sometimes go down. To be thourouigh, we only consider snapshots where the total number of cursors + the sums look the same. We have several snapshotrs to look at so we only keep numbers that seem growing steadily. We pay attention to the number of cursors that typically is 3700. The pin ration of SQL AREA is close to 100% so we though the approach was raesonable.
Thanks,
Claude