* Each CBC latch can cover a couple hundred chains. Once you realize Oracle can handle multiple CBC latches, you might jump to the conclusion that there will be one latch for every CBC. Oracle does not consider this necessary and feels comfortable with each latch being responsible for perhaps over a hundred chains.

* In every case, there are more chains than buffers. Not just by a few, but by two times or more. If there are more chains than buffers, this means some chains will not have an associated buffer header, effectively having a chain length of zero. While this may seem wasteful, it clearly shows that Oracle does not want a process consuming CPU resources, holding a latch and doing a sequential scan. It also implies the developers don't trust their hashing algorithm to not produce collisions. They decided it costs less (however that was measured-perhaps memory consumption) to increase the hashing structure size in the hope of saving CPU cycles and improving response time.

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.