Re: db_file_multiblock_read_count causing full scans to take longer?
- From: Kevin Lidh <kevin.lidh@xxxxxxxxx>
- To: don@xxxxxxxxx
- Date: Tue, 19 Dec 2006 13:26:54 -0700
Strangely enough, it was that same article which prompted my test on my
HP-UX 11.11 system with the same results as you (and the same question
on the list about a week ago). I would see it taking almost three times
as long to retrieve the same 128k of data in one I/O request with the
dfmrc set to 128 than when it was set to 16 with 8 I/O requests. I
looked at Metalink, and found a reference to maxio (assuming vol_maxio
on my system) and found that it's set to 256. The implication is that
the max I/O for my system is 256k so if my block size is 8k, the biggest
dfmrc I should have would be 32 (I'm testing this as I type). My
assumption is that if I set it higher, there is an attempt to make the
multiple I/O requests and assemble them into a single I/O response and
the overhead is the additional time. But that's speculation on my part
until I have concrete numbers.
On Tue, 2006-12-19 at 13:52 -0600, Don Seiler wrote:
> 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.
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
