As noted in the preceding list, during the one-hour period, total queue time (wait time) was 32,022 seconds. Since over the one-hour period, 5,400,000 user calls occurred, the average queue time per user call is 0.0059 sec/uc, or 32,022/5,400,000. For service time, Oracle consumed 39,960 seconds, and therefore the average service time for each user call is 0.0074 sec/uc, or 39,960/5,400,000.16

What is not graphically clear in Figure 1-4 is that nearly all the available database server CPU time is being consumed. Our simple calculation shows Oracle consumed 93% of the available CPU, which means that only 7% remained for all other processes including operating system activity, such as virtual memory management and process scheduling. The combination of Oracle's CPU consumption and the CBC latching issue will surely result in a raging CPU bottleneck.

Based on this abbreviated ORTA, an understanding of the Oracle architecture, and a little experience, there is an amazing array of possible solutions. From an Oracle perspective, you look for ways to reduce both the wait time and the service time by cleverly influencing Oracle. Wait-event analysis alone would not have exposed the CPU consumption issue. Knowing Oracle CPU time is greater than Oracle queue time is not enough information to devise a responsible solution. In fact, not considering response time could result in a reduction in wait time but a larger increase in service time!