The way I am reading Gregs questions, he is asking if service time means CPU time (sys + user). And that is correct. But this is all on the server side, so in Oracle ......
Anjo. Stephane Faroult wrote: > 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 > and probably many other things ... > > 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Anjo Kolk INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
