Let's take a look at another multiblock read call but using a different operating system tracing option. Look closely at Figure 2-7. Process 6852 was traced using the rp options. The r option shows the timing information at the beginning of the next line. For this example, the initial gettimeofday call took 0.000147 (s, or 0.147 ms. The 16 8KB block multiblock read request took 22.5 ms. This is much too slow for a respectable IO subsystem. Clearly, this IO request contains at least one block that resides on a physically spinning disk.

Figure 2-7. Oracle's instrumentation through an operating system lens. Oracle has submitted a multiblock IO read request to the operating system by issuing the operating system readv call. The call took 22.5 ms, which is much too long for most Oracle systems.

Do we cast the blame on the IO subsystem? While no one would be proud of a 22.5 ms IO subsystem response time, based on the 3-circle analysis, and unless there is a gross misconfiguration, performance optimizing solutions exist from Oracle, application, and operating system perspectives. Don't be quick to point the finger at the IO subsystem. And for you SQL tuners, don't immediately cast the blame on the SQL either, or you will be limiting your optimization opportunities.