The second part of Figure 2-15 lists the IO-related wait events, along with their wait-time percentage and also the average wait time. The average wait time for IO events provides a kind of backdoor view into how the IO subsystem is performing and also helps eliminate worthless IO-centric Oracle solutions. For example, if the average sequential read time were 1 ms, then asking the IO team for better performance could result in you being physical assaulted. The situation captured in Figure 2-15 shows multiblock reads are taking 36 ms to complete! That is a horrendous situation, which demands immediate attention from everyone involved.

As another example, suppose that you receive a call about long commit times. The users are saying "submits" or "saves" are taking longer today than yesterday. Upon an examination of the average log file sync wait times (which indicate commit times from an Oracle perspective), you discover there is no change from the previous day. Therefore, you know the performance issue is not because of Oracle's commit mechanism and most likely not related to the database.

Figure 2-16 shows a non-IO wait time summary, along with the underlying wait event detail. While most Oracle performance problems start out as an IO issue, after working on the problems, many turn into memory management issues. Depending on the event mix, sometimes I will perform an additional classification manually.