pabilities.
> -Original Message-
> From: K Gopalakrishnan [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 17, 2003 12:42 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: db file scattered read
>
>
> Mladen,
>
> I guess the rdbms kernel will be passi
Title: RE: db file scattered read
it does not. Try it out. The blocks in a multi-block read have to be
contiguous and Oracle can not guarantee that if the read would span an
extent boundary. I suppose Oracle could check, but that would likely incur
more overhead than you'd possibly
hitale [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 17, 2003 9:44 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: db file scattered read
>
>
>
> If 14706+3 is one extent and another extent begins at 14710,
> it will NOT read
> 14706+8. A DB_FILE_MULT
How can you tell that DB_FILE_MULTIBLOCK_READ will not span extents?
I was unable to confitrm that on Metalink.
> -Original Message-
> From: Hemant K Chitale [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 17, 2003 9:44 AM
> To: Multiple recipients of list ORACLE-L
> Subje
If 14706+3 is one extent and another extent begins at 14710, it will NOT read
14706+8. A DB_FILE_MULTIBLOCK_READ will not span extents.
Hemant
At 09:04 AM 14-03-03 -0800, you wrote:
Here is a part of trace file . I am finding that oracle is trying to read
8 or 3 or 7 blocks at a time . But block
It's doing that because it ISN'T reading
a sequential set of blocks. In my example
(taken from your original list) block 14,709
is presumably already in the buffer, so
Oracle has to read up to it, (which takes
three blocks), skip it, and then start again
at the block after.
Arguably it might be
Thanks Jonathen ,
But what I am pointing to is , why it is reading 3 blocks first time and
then 8 blocks next time , why not 8 blocks always .
Look at p3 which is no of block read .
-ak
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, Ma
The counts are inclusive:
14706 / 3 means
14,706 14,707 14,708
so you have to skip one then start
again at 14,710.
Yes, 'ela' is the elapsed time in 1/100 of a second.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Now available One-day tutorials:
Cost Based Optimisation
For the answer to your first question, see
Jeff Holt’s “Predicting
Multiblock Read Size” at www.hotsos.com/catalog.
Prior to Release 9, the statistic “ela= 1” means that the syscall lasted
somewhere between 0.005000 and 0.014999 seconds in duration. Full details
forthcoming in “Optimizing
