It may seem odd that a 120-second interval can show 621 seconds of wait time. This is very common in Oracle systems. The 621 seconds of wait time are the total wait time for all sessions during the 120-second interval. For example, if there were 1,000 sessions, and each session waited 1 second during the 120-second interval, then the total wait time would be 1,000 seconds. If 2,000 sessions each waited 2 seconds, then the total wait time would be 4,000 seconds. The more time processes wait, the more wait time. So one way to increase the wait time is to keep increasing the workload, which can be represented by the number of sessions or the work the sessions are doing.

If IO is an issue, you will certainly want to know if it's read- or write-focused. IO administrators can also benefit from knowing the type of IO load (read or write; single block or multiblock) Oracle is putting on the system. The Oracle IO-centric solutions are also very different based on the IO load type. An IO read issue can be minimized by keeping the more popular blocks in Oracle cache, whereas an IO write issue is minimized by core configuration issues, such as the number and size of the online redo logs.

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.