| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: The best CPU usage measurement in Oracle: BUFFER_GETS or CPU_TIME?
Binley,
I understand your point and I 100% agree with your option.
My point is: Today the better way (first look) to look on TOP SQL in the
reports like statspack (if we are trying to use statspack for some
purposes) is sort SQL by CPU_TIME because it is more accurate reflect CPU
usage by any SQL not BUFFER_GETS as it is right now.
Regards,
Jurijs
"Binley Lim" <Binley.Lim_at_xtra.co.nz>
Sent by: oracle-l-bounce_at_freelists.org
21.06.2004 15:57
Please respond to oracle-l
To: <oracle-l_at_freelists.org>
cc:
Subject: Re: The best CPU usage measurement in Oracle:
BUFFER_GETS or CPU_TIME?
> Lets me ask contrariwise question:
> Are there situations when using statspack report (if using) or other
> instance wide performance tool the better way to see TOP SQL-s is sort
by
> BUFFER_GETS not CPU_TIME?
>
I think that someone has already answered that "response time" is the far more important measure. Someone has also responded that you cannot pick BUFFER_GETS over CPU_TIME or vice versa for a number of reasons.
To look at TOP-SQLs, I would also look at EXECUTIONS and DISK_READS, and anything that appears in the top-list needs looking at. For eg, I had one situation where I missed the problem completely because BUFFER_GETS was nowhere near the top, but it was killing performance because it was constantly executing selects over a DB-link to check on a status_code that seldom changes. It was killing performance because it was flooding the network, not because it was doing a lot of BUFFER_GETS..
So it all comes down to "response time". But what is that creature? No one
can answer that. It depends on too many things, including -- OS vendors
typically try to optimize their kernels depending on what applications
(Oracle included) demand of it. And different OS vendors do different
things. The next OS release could be different, so any single Oracle
metric
that works now could no longer work in future.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon Jun 21 2004 - 09:12:10 CDT
 |
 |