If you're on a system earlier than Oracle Database 10g, the top wait event will be latch free, and as I detailed in Chapter 3, you will need to confirm the latching issue is the CBC latch. With Oracle Database 10g and later systems, as shown in Figure 6-14, the wait event will be latch: cache buffers chains. In most cases, the CPU subsystem will be heavily utilized and overburdened.

* Tune logical IO SQL. The CBC structure becomes stressed when the answer to the question, "Is the buffer in the buffer cache?" is nearly always "Yes!" If the answer shifts to "No, it's not in the cache," you will notice sequential or scattered reads will be the issue. So, from an application perspective, look for the SQL that performs the majority of buffer gets, that is, logical IO activity. The SQL statement or statements will be there-they must exist. Do whatever you can to reduce their logical IO consumption. This means classic SQL tuning, including indexing, as well as reducing the execution rate during the performance-critical times.

* Increase CPU power. In most cases, the CPU subsystem will be heavily utilized and probably the operating system bottleneck. Latch acquisition and the associated memory management consume a tremendous about of CPU. Do anything you can think of to reduce CPU consumption and to increase CPU capacity. Look for processes that do not or should not be running during peak times. Consider adding CPUs or using faster CPUs. If you are running in a virtual environment, considering ensuring this Oracle system has increased CPU resources. However, be aware that unless the application workload has considerably increased, additional CPU power typically will be consumed rather quickly. The real solution probably lies elsewhere. Increasing CPU power may be a good quick fix, but it will probably not truly solve the problem.