That description from X$KSPPI is out-of-date. Prior to release 7.3.4 this parameter used to set the size of a fixed table of buffer handles, and you would get an ORA-00371 error if a greater number of buffer handles were ever needed simultaneously. Nowadays the buffer handles are a segmented array in shared pool permanent memory, and this parameter just sets the initial size of that array. So now if you ever need a greater number of buffer handles simultaneously, the segmented array will just be extended.

It is still possible to get an ORA-00371 error if the shared pool does not have an adequate chunk of reusable memory to extend the segmented array, but that is not very likely. Amusingly, up to release 8.1.7 the suggested action in the error messages file and manual for this error is to increase the value of the db_handles parameter - which is a throw-back to version 6, because it's been a hidden parameter ever since release 7.0! However, I notice that in 9i they've switched to the more politically correct suggestion of increasing the shared_pool_size (which of course you can now do with an ALTER SYSTEM command under Oracle 9i).

Each buffer handle takes 100 bytes of memory, and the default number of buffer handles at instance startup is derived from the processes parameter. It used to be 2 times, and then 3 times processes, and under 8i it is now 5 times that value. You can see that default in X$KSPPSV (et al). More interestingly, V$SGASTAT often shows the amount of memory being used for db_handles, so you should be able to see from that whether the segmented array has been extended, and if so, how much memory it is now using.

There is a bug (1397603) affecting releases from 7.3.4 up to 8.1.7.1, but which is particularly severe at 8.1.7.x, that causes buffer handles to be leaked and in this case V$SGASTAT does not show the memory growth. The symptom is a continual growth in the number and total size of perm chunks in the shared pool, leading eventually to ORA-04031 errors. The normal workaround is to set _db_handles_cached to 0, but the performance impact of that is horrific in highly active instances. I understand that setting _db_handles_cached to 1 is also an effective workaround and has less severe performance consequences. There is a patch available for 8.1.7.1 on some platforms. The fix is in 9.0.1 and will be in 8.1.7.2.

Just taking a walk around the undocumented parameters and saw this one. Wondered if you have any experience tuning it:

_db_handles (System-wide simultaneous buffer operations)