The fact that there are so many CBC latches represents an interesting shift in Oracle's thinking. By limiting the number of latches, Oracle can control which processes can run its kernel code. If there are only ten latches, then Oracle's thought is that only ten processes could be on the CPU. This way, Oracle developers thought they could help ensure the CPU subsystem is not being overwhelmed by Oracle processes. But this is bad policy and thinking for two reasons. First, if a process does not have a latch but wants one, the process will be repeatedly spinning and sleeping. As we know, spinning consumes CPU. So regardless of whether a process has the latch and is running kernel code or is spinning on a latch, CPU will be consumed. The only benefit is when sleeping is involved, which will reduce CPU consumption. Second, when Oracle tries to control this process, it is effectively saying it knows better how to balance operating system resources. I think Oracle developers learned it is best to liberally give latches to reduce any contention involved in acquiring the latch, and then let the operating system deal with the scheduling issues.

This does bring up an interesting point though. Latch contention can be the result of time spent acquiring the latch, not only time holding the latch. It is sad indeed when significant resources are used to simply acquire the latch and not actually do the database work we desire.

I suspect many of you are now anxious to see what the situation is on your system. The script in Figure 6-10 will produce the raw numbers you need. Because the query is against x$ performance tables, you'll need to be connected as sysdba. The instance parameters are fairly self-explanatory, but are detailed in Table 6-2.