Re: Extended SQL Trace Interpretation Question
- From: mkb <mkb125@xxxxxxxxx>
- To: Cary Millsap <cary.millsap@xxxxxxxxxxxx>
- Date: Fri, 30 Oct 2009 12:59:16 -0700 (PDT)
Cary,
I hadn't gotten that far. Having finally read that section, it's all beginning
to make much more sense.
Interesting read on gettimeofday and getrusage and how they report time. Will
definitely re-read a few times to get the full picture.
Thanks for pointing me in the right direction.
--
mohammed
________________________________
From: Cary Millsap <cary.millsap@xxxxxxxxxxxx>
To: mkb125@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Sent: Wed, October 28, 2009 5:44:18 PM
Subject: Re: Extended SQL Trace Interpretation Question
Mohammed,
See pages 161–164 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@xxxxxxxxx> 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
>
>
>
>
>>--
>//www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
