I agree. And that's what we get on the PARSE, EXEC, FETCH, UNMAP, SORT UNMAP, and STAT lines. It's not presented in a lot of detail, but it's a tradeoff between detail and measurement intrusion. There's certainly more detail available; for example, events 10104, 10200, etc., but the measurement intrusion is significantly greater for some of those events than it is for 10046. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Nullius in verba Hotsos Symposium 2007 / March 4-8 / Dallas Visit www.hotsos.com for curriculum and schedule details... -----Original Message----- From: Dimitar Radoulov [mailto:cichomitiko@xxxxxxxxx] Sent: Tuesday, May 02, 2006 4:51 PM To: Cary Millsap Cc: oracle-l@xxxxxxxxxxxxx Subject: Re: *Measuring sql performance (elapsed time and scalability) by number of logical reads On 5/2/06, Cary Millsap <cary.millsap@xxxxxxxxxx> wrote: > In the trace data context, those things listed below (hash value > calculation, memory management, traversing hash chains, etc.) will show > up as time in the c field. ...Not as time in a "wait" event. > > I don't think the categorization "service" vs. "wait" helps people's > thinking very much. > A better way to think of the time being spent from > Oracle's perspective is "kernel code path" vs. "OS call code path". > Roughly speaking, the c field on a dbcall maps to kernel code path > execution, and the ela field on so-called "wait" lines maps to OS call > code path execution. I think that instrumenting oracle kernel code path is as useful as OS call code path instrumenting is. > Notice that an OS call duration includes both waiting and service time. > This is the reason I don't like to use the word "wait interface". > > > Cary Millsap > Hotsos Enterprises, Ltd. > http://www.hotsos.com > Nullius in verba > > Hotsos Symposium 2007 / March 4-8 / Dallas > Visit www.hotsos.com for curriculum and schedule details... Regards, Dimitre -- //www.freelists.org/webpage/oracle-l