It also depends on the definition of ‘multiblock IO’: if you look at the control file wait events, at least the waitevents have the ability to report time taken to do IO for reading/writing multiple blocks. But these are not database blocks, but controlfile blocks. The same is true for the log file related waits.

If we start to get really creative, but also not get away a bit from physical IO, you could also wait for multiple blocks from a remote cache with RAC with the ‘gc cr multi block request’ request. Or is that too far off?

Thank you for the reply. Your comment is a little short in terms of context. I *think* that you are indicating that fast full index scans are also likely to perform multiblock IO. If that is the case, I think that your comment applies to the second half of my previous response. Nice addition.

(I need to determine if Cary was stating that my blog articles/comments were faulty, or if he was commenting that I am pointing out a lot of silly mistakes that are written in books, blog articles, and commercial websites.)

So, how is it that my netbook running Window 7 Professional and Oracle Database 11.2.0.1 are able to see 0.6ms access times for multiblock reads? Oracle running on the Windows platform uses direct, asynchronous IO, so there is no help from the operating system file cache. A couple of possibilies:
* Many hard drives will have at least 8MB of built-in cache memory, and possibly 32MB (or more) cache memory. I believe that my netbook’s hard drive has 16MB of built-in cache, and it may be performing read-ahead optimization.
* The disk controller may have a built-in cache set to read-ahead caching – predicting the next piece of a file that will be read. In my case, the disk controller does not have cache memory.
* The disk head might have been in just the right location over the spinning platter to quickly pick up the data from the drive.
* I might have the netbook connected to a SAN (this is not the case).
* There might have been unaccounted for time that helped the drive platter rotate into position before timing started (see the latest Quiz Night article on Jonathan Lewis’ blog for an example).
* The hard drive in the netbook might be a hybrid – part SSD and part spinning rust (this is not the case).
* The hard drive might actually be a SSD (this is not the case – yet).

—
Now on to another problem that I have with the quote. “Oracle gives a multiblock IO call the special name db file scattered read.” What could be wrong with this statement – yes, a multiblock IO *could* be reported as a db file scattered read:
* On Oracle 11.1.0.6 and above, Oracle just might decide to do a direct path read rather than a df file scattered read while performing a full table scan – I do believe that a direct path read could be a multiblock IO. Direct path reads are also used during parallel execution.
* Index pre-fetch might use a db file parallel read, where multiple non-adjacent blocks are read in a single IO call – I believe that type of access could be considered a multiblock IO.
* The direct path read temp wait events might appear as a result of a multiblock IO of a temp tablespace.

So, what has yet to be mentioned about the quote?

I faintly remember reading something like that also, but cannot find the source. I paged through the “Oracle Insights – Tales of the Oak Table” book and did not find it in that book (I could have overlooked it – if someone finds it, please provide a reference to the source). I searched and found a reference in the “Oracle Wait Interface” book (one of that book’s authors was a technical reviewer of the Firefighting book):
http://books.google.com/books?id=14OmJzfCfXMC&pg=PA55&

That book points back to an article that Jeff Holt (worked on the “Optimizing Oracle Performance” book) wrote which was titled “Why are Oracle’s Read Events ‘Named Backwards’? A search for that article lead me to this page:
http://www.hotsos.com/e-library/abstract.php?id=16

From that article (page 1):

“The UNIX read() function reads a contiguous portion of a file and stores it contiguously in a single memory area. The readv() function reads a contiguous portion of a file and stores pieces of that data in different areas of memory dictated by an array of memory references. Oracle disk-reads executed through calls like read() are recorded as db file sequential read events, and disk-reads executed through calls like readv() are recorded as db file scattered read events.”

The article also explains why the faster disk access provided by the read() function was not used for multiblock reads.

So, what kind of a parallel read operation is the book author describing that allows Oracle to read multiple non-sequential blocks in a single call? I wonder if that operation is handled by the readv() function?

Anything else wrong with the quote? Here is a hint:
My netbook, running Windows 7 Professional and Oracle Database 11.2.0.1, is able to report read times on db file scattered read events of less than 0.6ms (the author was talking about multiblock reads of 16 blocks of 8KB size, just 128KB per read request).