RE: *Measuring sql performance (elapsed time and scalability) by number of logical reads

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: "bill thater" <shrekdba@xxxxxxxxx>
  • Date: Wed, 3 May 2006 10:56:30 -0500

I very rarely see the intrusion change the fundamental nature of the
problem. ...In my experience, you most often end up with an appropriate
diagnosis in return for some small number of times that you cause the
performance intrusion.

10200 is especially intrusive, because it emits a line of text to the
trace file for every buffer cache access that takes place.


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: bill thater [mailto:shrekdba@xxxxxxxxx] 
Sent: Wednesday, May 03, 2006 10:20 AM
To: Cary Millsap
Cc: Dimitar Radoulov; oracle-l@xxxxxxxxxxxxx
Subject: Re: *Measuring sql performance (elapsed time and scalability)
by number of logical reads

On 5/3/06, Cary Millsap <cary.millsap@xxxxxxxxxx> wrote:
> 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.

is it great enough to skew the results?


--
--
Bill "Shrek" Thater     ORACLE DBA
       shrekdba@xxxxxxxxx
------------------------------------------------------------------------
"All the girls say
Save a horse, ride a cowboy."
--
//www.freelists.org/webpage/oracle-l


Other related posts: