Be careful about making assertions when there are not very many samples. For example, during the 30-second interval between reports, single-block read requests (event db file sequential read) took an average of 8.2 ms, but Oracle server processes issued less than 1,000 of them. Another more pronounced example is log writer multiblock writes (event log file parallel write) took an average of 49.0 ms! Normally, that would be unacceptable, but they occurred less than 1,000 times during the report interval, and their combined time accounts for only 0.45% of the wait time. So this is nothing to be concerned about.

Table 4-1 lists the Oracle-related wait events that can be useful in understanding IO subsystem response time. When focusing on the IO subsystem, and not analyzing Oracle response time, I am primarily concerned with multiblock writes, and single-block and multiblock reads. My general rule of thumb is a 10 ms response time. Different applications will have different service-level requirements, but this is a good general guideline. The wait event log file sync is how long commits take from an Oracle perspective. I've seen commit time requirements range from 2 to 100 ms. So it really depends on your objectives. However, in a top-of-the-line IO subsystem, you can expect IO read and write response time to be well within 10 ms.

Figure 4-20 is an AWR report's Top 5 Timed Events table, showing wait events. Notice that multiblock reads (event db file scattered reads) are taking an average of 20 ms to be returned to an Oracle server process. This normally would not be acceptable. Now, I am not implying the IO subsystem is improper in some way and I'm also not implying the Oracle instance or the related SQL is tuned. All we know from this report is that when Oracle server processes submit a multiblock IO request, it takes the IO subsystem 20 ms to respond. Based on the associated OraPub 3-circle analysis, there will most likely be at least three possible, and probably more, solutions.