Re: *Measuring sql performance (elapsed time and scalability) by number of logical reads
- From: "Morten Egan" <meg@xxxxxxxxxxxx>
- To: cichomitiko@xxxxxxxxx, "Bernard Polarski" <bpolarsk@xxxxxxxxx>
- Date: Tue, 02 May 2006 14:18:45 +0200
A logical IO is not a logical IO :)
There are many diff. types of logical IO in oracle, and many of them involve
completely different code paths, taking diff. amounts of time to complete.
Regards,
Morten Egan
-----Original message-----
From: "Radoulov, Dimitre" cichomitiko@xxxxxxxxx
Date: Tue, 2 May 2006 14:08:53 +0200
To: "Bernard Polarski" bpolarsk@xxxxxxxxx
Subject: Re: *Measuring sql performance (elapsed time and scalability) by
number of logical reads
> >I think you have been a bit short in the problem description.
> >
> > You just meant that all the requested data is already in buffer and no
> > physical read is needed.
> > Thanks but we have no information on the nature of the sql, the amount of
> > data, the expected goal.
> > Bad or good SQL is a ratio of these. What if I read one million blocks
> > from my multi gig db block buffer
> > to return a tiny rowset for the worse ever seen SQL, it will satisfy your
> > prerequisite and still be very bad.
>
> Excuse me for not being clear, I meant, theoretically speaking:
>
> SQL 1 reads n1 blocks from buffer (no physical read) to complete, elapsed
> time t1
> SQL 2 reads n2 (where n2 > n1) blocks from buffer (no physical read) to
> complete, elapsed time t2
>
> t1 is greater than t2
>
> Always theoretically/hypothetical speaking:
> could anyone comment the possibile reasons behind such behaviour.
>
>
>
> Regards,
> Dimitre
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
