To summarize, the Oracle subsystem is being forced to ask for blocks outside its cache. While the operating system returns these blocks extremely fast, the number of requests results in a significant portion of the total response time. From a purely Oracle perspective, we can easily reduce the queue time by 20% by simply increasing Oracle's buffer cache.

Figure 9-21 provides the core Oracle diagnostic information collected over a 30-minute interval in a response-time analysis format. At this point in the book, you should know the service time CPU information came from v$sys_time_model and the queue time information came from v$system_event. All wait events that consumed more than 5% of the wait time during the reporting interval are included in this analysis and shown in Figure 9-21. Clearly, the top wait event is db file scattered read, yet the average wait time is only 0.093 ms! So, it's the classic situation where the requested blocks are not in Oracle's buffer cache, but the operating system retrieves them very quickly. If the system were bottlenecked, we would expect to find a raging CPU bottleneck. Otherwise, the sheer number of buffers Oracle must process, combined with the CPU speed, is resulting in unacceptable performance.

Figure 9-21. Shown is the ORTA information entered into a firefighting diagnostic template, which makes diagnosing, analyzing, and anticipating change impact much simpler. Clearly, db file scattered reads events are the issue. While the CPU subsystem capacity is not shown, Oracle is consuming only 26% of the available CPU resources.