"Pablo Sanchez" <pablo_at_dev.null> wrote in message news:<3ce3f0e2$1_19_at_news.teranews.com>...
> Howdy!
>
> Being that we're on the topic of myths, I have in my very old Oracle 7
> Performance and Tuning book that says on page 6-7:
> ----8-<---8-<---8-<---8-<---8-<---8-<---8-<---
> How is the buffer cache managed?
> --------------------------------
> ...
> When the server is using index access, it always reads in one block at
> a time, never multiple blocks.
> ...
> ----8-<---8-<---8-<---8-<---8-<---8-<---8-<---
>
> My take on that line at the time was that we're not sorting the
> database blocks within an extent. That what we are doing is
> maintaining a doubly-linked chain of DB blocks within the extent,
> which is why there is no "index_multiblock_read" (at least not in 8i)
> need.
>
> Questions:
> ----------
> 1) In 8i and above, are our server processes still doing a single I/O
> at a time when running, say, an index range scan?
> 2) If we're doing 1), is the reason because of what I guessed?
> 3) If 1) again, any plans to start storing the data sorted so we can
> do "index_multiblock_read"s? I realize that there's a hit on changes
> to the b-tree because we'd have to rebalance the tree and possibly
> affect many DB blocks.
Forcing index blocks to be physically sorted will create too much overhead
for DMLs. I hope Oracle won't do that.
Received on Fri May 17 2002 - 16:33:03 CDT
