Re: db_file_multiblock_read_count causing full scans to take longer?

For reference, this was the guide I was following: http://www.dizwell.com/prod/node/436 . HJR makes a case for not having to flush the buffer cache. However it's possible that I incorrectly assumed that applied to me.

Don.

On 12/19/06, Christian Antognini <Christian.Antognini_at_trivadis.com> wrote:
> Don
>
> > FWIW I did do 10046 traces of non-parallel full scans using various
> > db_file_multiblock_read_count values, from 16, 32, 64, 128, and 256.
> > 128 seemed to be where it topped out. However I'm finding the poor
> > performance at anything over 32 now.
>
> Be careful, the performance of non-parallel FTS is highly dependent on
> the blocks already stored in the buffer cache. In fact Oracle never
> reads a cached block...
>
> Therefore, to find the best db_file_multiblock_read_count, it makes
> sense to flush the buffer cache before each FTS.
>
>
> HTH
> Chris
>

--
http://www.freelists.org/webpage/oracle-l