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!

Oracle-focused solutions will zero in on reducing both service time and queue time. CBC latch contention indicates a high level of buffer activity, which consumes CPU. So you start thinking of creative Oracle-centric ways to reduce the amount of buffer cache activity. You also expect, and will be looking for, high buffer get (that is, logical IO) SQL during your application analysis. From an Oracle queue time perspective, a possible solution is to increase the number of CBC latches. (Many other solutions will be presented in Chapter 6, which covers Oracle buffer cache internals.) The key is to focus on reducing the response time, not just the service time or the wait time.