Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Response time analysis and TKPROF
Greg Moore wrote:
>
> For a single SQL statement, I'd like to determine the response time
> components.
>
> Since TKPROF output provides totals for Elapsed Time and CPU Time, is it
> correct to say that the "service time" component is total CPU, and the "wait
> time" component is total Elapsed Time minus total CPU time?
>
> Is this formula perfect, a very good and workable approximation, or way off?
>
Greg,
Sorry for saying so, but I think that you are erring (unless it's me). What is for you the 'service'? I presume that it's getting your result from Oracle. So your server is Oracle. But your server itself is at the mercy of a number of things and can wait for :
a) CPU, b) a latch, c) a lock, d) I/Os
Elapsed time minus CPU time is certainly a 'wait time' component, but some of this 'wait' can be a perfectly legitimate part of the 'service' - such as waiting for a latch or bringing the block into memory.
Queue theory is indeed very interesting, but what do you want to do with
it? As I see it, the benefit of knowing service time and wait time is to
say 'well, if I want to ensure that say 90% of my clients do not spend
more than xxx time units in the system, then I must have that many
servers'. Great for sizing hardware, but I am afraid that tackling the
problem as you are trying to do it cannot lead anywhere. You cannot add
more of the same SQL query, can you? I mean, can you apply queue theory
when servers are brought in by clients? Or your query is just a part of
a 'service' as a transactional monitor understands it, which is, to me,
a bit different.
My feeling is that it is wrong to see one SQL statement as a service. A
business process is a service, and you can diminish service time by
tuning your code - and I am a bit confused about wait times at this
level.
The (primitive) way I see elapsed time and CPU time in tkprof output is
that first elapsed time is how users see it. If the number of logical
reads is high, I have a problem (either the query is inherently costly,
either it is poorly written). If I have a high number of logical reads,
it is somewhat normal to have physical reads as well, and therefore a
significant difference between elapsed and CPU time(I/O waits). If I
have no physical I/O and a huge difference between CPU and elapsed time,
then either I have locking problems or the system is in a sad state. And
so on. But I find theorizing difficult at this level.
Contradictors welcome :-).
-- Regards, Stephane Faroult Oriole Software -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephane Faroult INET: sfaroult_at_oriole.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Sat May 04 2002 - 16:58:19 CDT
![]() |
![]() |