Table 6-1 shows a few samples of the relationship between data buffers, CBCs, and the CBC latches. Each sample was taken from a real production Oracle system. Only the number of data buffers was set; that is, all the other values were defaults based on the number of data buffers. Based on the number of data buffers, Oracle determines the number of hash chains and the number of latches.

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