The formulae for the number of cache buffers chains latches under 8i were mentioned in last November's Ixora News.

It is highly unlikely that the latch contention you are seeing has anything to do with the number of child latches. Rather if you check V$LATCH_CHILDREN you should see that the sleeps are heavily skewed to just a few child latches. I expect that these latches protect key blocks from one of the space management data dictionary clusters (C_TS#) that you are using intensively. Specifically it may be that you degraded the performance of this cluster by allowing one or more tablespaces to have thousands of free extents and SMON is trying to coalesce them. If this analysis is right, you should drop and recreate this tablespace under a different name, or better, rebuild the entire database, and henceforth be more careful about allowing extents to proliferate in this way.

Could you explain the relationship between the db_block_buffers and the number of cache buffers chains latches. My understating is that the number hash buckets is equal to a prime number >= db_block_buffers/4 and the each hash bucket is covered by a cache buffers chains latch. However in our database with 120000 buffers I see only 1024 latches in the V$LATCH_CHILDREN view and when the buffers are bumped up to 150000 the number of latches increased to 2048.

We are having a tremendous performance problem when we try to run a query against DBA_TABLESPACES and DBA_FREE_SPACE to determine free space. All the time the query is running I see latch free wait on cache buffers chains latch. Also, I see the SMON process is constantly running and the wait event on SMON, most of the time is cache buffers chains latch free waits.