* Take a look at the requested block size and the number of blocks requested. If you are familiar with Oracle, you'll immediately notice that we are looking at an 8KB database, and Oracle is asking for 16 blocks at once. And you are correct if you guessed the instance parameter db_multiblock_read_count is 16!

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.