Re: db_file_multiblock_read_count causing full scans to take longer?
- From: "Paul Drake" <bdbafh@xxxxxxxxx>
- To: Brandon.Allen@xxxxxxxxxxx
- Date: Tue, 19 Dec 2006 15:11:29 -0500
On 12/19/06, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> 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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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.
Other related posts:
