Yes, it does indeed happen that Oracle requests large multiblock I/O operations that the operating system cannot satisfy in a single physical request. Other than the MAXPHYS limit, there are logical track boundaries in LVM, stripe boundaries, and so on, which sometimes require multiblock read requests to be serviced via a number of smaller physical requests.

Nevertheless, it remains best to allow Oracle to use large multiblock reads, as long as the optimizer is not doing inappropriate full scans. The explanation relates to the system call and context switch overheads associated with I/O. It is cheaper in CPU usage terms to request a 256K I/O and allow the operating system to service it in 64K chunks, than to request 4 I/O's of 64K each. As is mentioned in the tip on Why Large Multiblock Reads, the increased latency is not an issue because multiblock reads should not be used in cases where "first rows" response time is critical.

I had some questions regarding the method devised by you for finding the maximum multiblock I/O possible on a given platform. The trace file generated by the script shows what is the maximum number of bytes read by Oracle in any single read() call, which can also be verified by truss. However in my opinion it is possible for the Operating System device driver to break up this single read call internally into a number of smaller I/Os each of which does not exceed the maxphys kernel limit on that platform. As this happens in kernel mode, there is no way in which truss or Oracle can report this i/o size. Thus we could have a situation where maxphys is say 64KB, and Oracle gives a read call of say 256 KB, but the kernel device driver breaks this up internally into 64KB chunks. Thus although Oracle trace and truss would report a maximum i/o of 256 KB, internally it is actually still being restricted to 64KB. In this case would it not be prudent to set db_file_multiblock_read_count to 64KB instead of 256KB? Is it possible that Oracle queries the OS and finds the value of maxphys on the host and automatically limits the maximum size of each individual read call to maxphys? Could you please comment whether the scenario painted above is likely?