Digging a little deeper, we can assert that all the requested blocks must have resided in memory (but not Oracle's buffer cache memory, since Oracle needed to request them from the operating system). We can make this assertion because a physical spinning IO device cannot return 16 nonsequential blocks (the blocks could be scattered over many physical devices) in less than a single millisecond!

Oracle's wait interface takes this timing information, gives the system call a special nonplatform-specific name, records the timing information, and makes this all available to us through its performance views. Regardless of the operating system or the actual system call, Oracle gives a multiblock IO call the special name db file scattered read, because these multiple blocks can be scattered over the IO subsystem. This Oracle-given name is more commonly called an event name, a wait event, or simply an event. From a performance analyst perspective, we tend to think of a multiple-block request as a sequential request, but looking at the IO call from a more kernel-centric perspective, it is more appropriate to name the request a scattered read.

Oracle associates the wait event name with the wait time, which in Figure 2-6 is 0.6 ms. If we had been looking at server process 14558 through Oracle's wait event interface during the time of the Figure 2-6 trace, we would have seen the server process was posting a db file scattered read. I like to say that the Oracle process is yelling out the wait event as it impatiently waits for the operating system to return the requested blocks. After the server process was done waiting, we would see that the time waited was 0.6 ms. So, in a very real way, Oracle has made this tracing information available to us without tracing, but through its wait interface. Beautiful simplicity!