* There are a lot of hash chains. While I'll illustrate perhaps five to ten chains when explaining CBCs, in reality, there are thousands or millions of them! Oracle knows its hash function is not perfect and will result in some collisions. One way to reduce the likelihood of collisions is to have a larger number of chains. Your first reaction may be that more chains will consume more memory, but this is not true. Each buffer header must be on a chain, regardless of the number of chains and the chain length. With more chains, the average chain length decreases, while the number of buffer headers does not change. So, while there is some additional memory overhead for each chain, the real memory consumer is the number of buffer headers, not simply the number of chains.

* There are thousands of CBC latches. Years ago, the rule of thumb for the number of latches was that they should not exceed the number of CPU cores times two. Obviously, Oracle has changed the rules, because I know for a fact that none of the Table 6-1 systems has over 500 CPU cores! And don't forget that the CBC latches represent only one of the many latches Oracle uses (last count on an Oracle Database 11g system was 382 latches).

* 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.