Re: db_file_multiblock_read_count causing full scans to take longer?

On 12/19/06, Allen, Brandon <Brandon.Allen_at_oneneck.com> wrote:
>
> Hi Christian,
>
> By flushing the buffer cache before your testing, aren't you going to be
> testing and optimizing based on an unrealistic scenario? Why tune for
> all blocks being uncached if that will not be the typical case?
>
> Thanks,
> Brandon

Brandon,

I can see testing with a flushed buffer cache to set the possible high end target and then assume that the average result will be about 42 percent of that. At best.

Don,

Do you know what the underlying stripe size is of the volume where the datafiles reside?

Paul

-----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Christian Antognini
>
> Therefore, to find the best db_file_multiblock_read_count, it makes
> sense to flush the buffer cache before each FTS.
>
>
>

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