The worksheets shown in the figures in the remainder of this chapter are all contained within a single Microsoft Excel workbook, the firefighting diagnostic template workbook.12 Only the yellow cells require input. If you enter information into a cell that isn't shaded yellow, you are typing over a formula! Data entered in one of the worksheets may be referenced in another worksheet. For example, the Oracle CPU consumption shown in the Oracle-focused worksheet (Figure 9-21) is referenced in the operating system CPU analysis worksheet (Figure 9-22). All the data-entry fields have been previously discussed. If you need more information about their source, please review the appropriate section in this book.

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.