Re: Extended SQL Trace Interpretation Question

From: Cary Millsap <cary.millsap_at_method-r.com>
Date: Wed, 28 Oct 2009 16:44:18 -0500
Message-ID: <3a2a84fc0910281444s679d7b81j9f2c1c6662294770_at_mail.gmail.com>



Mohammed,

See pages 161164 of the same book. It boils down to the fact that the c statistic comes from a less granular clock than the e statistic.

Cary Millsap
Method R Corporation

http://method-r.com
http://carymillsap.blogspot.com
http://twitter.com/cary_millsap


On Wed, Oct 28, 2009 at 3:32 PM, mkb <mkb125_at_yahoo.com> wrote:

> I traced a very simple SQL statement (10046 level 12). Something like:
>
> select id from issues
>
> which returned 195 rows.
>
> Here's a snippet from my trace file and on the PARSE line I get the
> following:
>
> PARSING IN CURSOR #5 len=40 dep=0 uid=49 oct=3 lid=49 tim=1227288824370256
> hv=1876028296 ad='777f6f40'
> select id from issues
> END OF STMT
>
> PARSE
> #5:c=11998,e=11427,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1227288824370250
>
> BINDS #5:
> EXEC #5:c=0,e=82,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1227288824370419
>
>
> My understanding was that the e ~ c + SUM ela (Optimizing Oracle
> Performance, Ch 5 p87, Millsap). So why is my e value less than my c value?
> Should it not be greater than or equal to my c value?
>
> Database is 64-bit 10gR2 EE on RHAS 4u7.
>
> Thanks
>
> --
> mohammed
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 28 2009 - 16:44:18 CDT

Original text of this message