Very well stated response. I agree completely with the listed shortcomings of that sections of the book and how to improve the book. Regarding your OTN comment, I think that it is hard for people to initially understand that a “Top 5″ report will always have something in the “Top 5″, and that something is usually an I/O type of wait event in a well performing database instance.

My problem with the above text is non version specific. It just isn’t clear what Don means by Excessive and High in the extract above. In the case of the db file sequential read then there are about 2k single block reads recorded in the timespan of the report – we don’t know what that timespan is Don doesn’t say (and so we can’t draw his conclusion that it is I/O bound even) – but 2k disk reads in a timeframe that you can do 25k multiblock reads doesn’t seem excessive. In that case perhaps he means excessively long. Now this makes more sense since his single block reads took on average nearly 3 seconds if the output is to be believed (Frankly I don’t believe it to be reliable but anyway). However the High multiblock reads take on average a reasonable time (and the examples given strongly suggest that High doesn’t mean slow, but caused by workload or server configuration issues).

This section of the book would have been so much better if

1) We had a time frame to understand how Don drew his conclusions – in fact each report should have the timeframe and cpu count listed as the original report does
2) We had a clearer definition of Excessive and High (maybe single block reads that take longer than 20ms for Excessive wait times, or more than 100 IOPS/Underlying Disk for high wait counts.

It would be perfectly reasonable for the casual reader to conclude that any system where these 2 disk events are the top 2 is Disk I/O bound – in the sense that Disk I/O is constraining performance. I’ve seen enough examples of statspack reports on otn and elsewhere where help with the disk subsystem is sought for databases that appear to be on average idle to know that folk do just look at the names of the top events and think that this tells them something about the database application they have.