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

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