Re: my max db_file_multiblock_read_count is 128.. why?

andreyNSPAM_at_bookexchange.net (NetComrade) wrote in message news:<3d6a6e60.1484346567_at_news.globix.com>...
> [lroot/dragon@: ]echo 'vol_maxio /D' | adb -k
> physmem 1390ee
> vol_maxio:
> vol_maxio: 512
> (256K)
>
> [lroot/dragon@: ]echo 'maxphys /D' | adb -k
> physmem 1390ee
> maxphys:
> maxphys: 131072
> (128K)
>
> Oracle Block size=4K
>
> So I'd expect my max multi_block_read to be 64 (or even 32, not 100%
> sure if maxphys has anything to do w/ vxfs)
>
> however
> multiblock_read_test.sql (from Steve Adams/ixora.com.au)
> shows that it's 128
>
> Are oracle reported scattered reads not actual physical reads?
>
> Any extra insight is appreciated.
> .......
> We use Oracle 8.1.7.3 on Solaris 2.7 boxes

Hi, NetComrade,

You asked a very interesting question. I don't know the answer for sure. But I suspect that Oracle only knows down to the logical I/O level, i.e. the file system level, I/O size. In your case, your vxfs I/O size is 512K, the same as
db_file_multiblock_read_count*db_block_size. According to http://docs.sun.com/?q=tuneable&p=/doc/816-0607/6m735r5ev&a=view, maxphys is the "Maximum size of physical I/O requests... File systems can and do impose their own limit". (In your case, the filesystem limit is larger rather than smaller) I suspect that if you do a benchmark, you may find that setting db_file_multiblock_read_count over 32 (thus I/O chunk size is 128K) improves performance only very little or not at all. If it does still improve slowly, there may be some benefit of vxfs queuing a big chunk even if the device serializes the processing.

I know and I tested on UFS, setting this parameter does not improve table scan performance, explained by Steve Adams. I'm anxious to see your benchmark on vxfs.

Yong Huang Received on Tue Aug 27 2002 - 15:18:53 CDT