One way to look at the contention possibility is to calculate how many chains each latch protects. For example, if there are 10,000 chains and 1,000 latches, then each latch ensures serialization for 10 chains.

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.