Yes, that is the way it is meant to be under 8.1. It is not a bug. As you say, (from 7.1) up to release 8.0 the number of hash buckets was the next prime greater than or equal to db_block_buffers/4, and there was a distinct child cache buffers chains latch for each hash bucket. However, under 8.1 the number of hash buckets has been increased to 2*db_block_buffers and many hash buckets share the same child cache buffers chains latch.
The number of latches can be tuned directly with _db_block_hash_latches but the value is constrained to a binary power. By default, the old ratio of 1:4 is maintained for small caches (less than 2052 buffers) and a ratio of about 1:128 applies for large caches (more than 131075 buffers) with 1024 latches being used for medium sized caches. The exact formulas for small and larges caches seem respectively to be
2 ^ trunc(log(2, db_block_buffers - 4) - 1)
and
2 ^ trunc(log(2, db_block_buffers - 4) - 6)
I believe that the reason for the change is that the correct hash latch to use
can now be determined with a SHIFT rather than a DIVIDE operation, which is
clearly going to save CPU time. Given the frequency of this calculation, Oracle
must have found that this saving in CPU time warranted the increased risk of a
skewed distribution of activity against the child latches.
I am at a site where they using 8.1.6.0 on HP-UX 11.0.
It used to be that the hash buckets where db_block_buffers/4 increased to a prime number. I have two different databases
o1 has 50000 16k blocks and the _db_block_hash_buckets are 100000
hr3 has 25000 16k blocks and the _db_block_hash_buckets are 50000
the information for hash buckets are coming from X$KSPPI and X$KSPPCV joining on INDX.
But when I do a count on the child latches both instances have 1024 children. So I have 50 blocks hashed to a single latch on o1 and 25 hashed to a single latch on hr3. Is this the way 8i is suppose to be? Is it a bug?