Re: db_file_multiblock_read_count causing full scans to take longer?

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.
> 


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

Other related posts: