RE: cpu time and query column in tkprof output

I'm almost positive that the byte counts on these two statistics are incorrect anyway... At least, the byte count on these two events as published in the 10046 output is ALWAYS incorrect (they always say p2=1, which is always wrong). You can verify this yourself with strace.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:

- Performance Diagnosis 101: 2/23 Houston, 3/16 Salt Lake City
- SQL Optimization 101: 2/7 Dallas
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Wolfgang Breitling
Sent: Wednesday, February 02, 2005 8:35 AM To: yasbs_at_kocbank.com.tr
Cc: oracle-l_at_freelists.org
Subject: Re: cpu time and query column in tkprof output

Why is there a difference in bytes sent/received via SQL*Net between the two cases? If both do the same, shouldn't at least bytes sent be the same?

Yasin Baskan wrote:
> I have the following statistics for the one with less cpu time and less
> elapsed time:
>
> Statistics
> ----------------------------------------------------------
> 0 recursive calls
> 62 db block gets
> 11407 consistent gets
> 14 physical reads
> 0 redo size
> 189 bytes sent via SQL*Net to client
> 791 bytes received via SQL*Net from client
> 3 SQL*Net roundtrips to/from client
> 5 sorts (memory)
> 1 sorts (disk)
> 1 rows processed
>
> And the following statistics are for the one with more cpu time and
> elapsed time:
>
> Statistics
> ----------------------------------------------------------
> 0 recursive calls
> 58 db block gets
> 4108 consistent gets
> 155 physical reads
> 0 redo size
> 204 bytes sent via SQL*Net to client
> 657 bytes received via SQL*Net from client
> 3 SQL*Net roundtrips to/from client
> 5 sorts (memory)
> 1 sorts (disk)
> 1 rows processed
>
> The number of sorts is the same. The one with more cpu time has 141 more
> physical reads but much less buffer gets. Then the idea of focusing on
> logical reads and ignoring physical reads is not true for this case. Do
> you suggest using the one with more cpu&elapsed time but less buffer
> gets or the one with less cpu time but more buffer gets?
>

-- 
Regards

Wolfgang Breitling
Centrex Consulting Corporation
www.centrexcc.com
--
http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l