When a process needed memory in the shared pool, its resulting hash bucket and chain were related to the memory size required. The chains are commonly called a heap, which is a linked list of available memory chunks. So conceptually, the first few chains were related to around 1KB chunks of memory, the next few chains were related to around 2KB chunks of memory, and so forth. While this was indeed ingenious, after a while of allocating and deallocating memory of nonuniform sizes, the chains could become literally a few thousand nodes long. Keep in mind the hash buffer chain size averages between zero and one. So a chain of a couple thousand nodes is massive. And to make matters worse, there was only one single shared pool latch to cover all the hash chains! Flushing the shared pool helped quite a bit because the chains would be reduced to a respectable size. But that was no way to operate a large production database, so Oracle had to make a change.

Oracle9i introduced subpools, which naturally lead to multiple shared pool latches. The hashing-based strategy was replaced by a multiple subpools, each containing a single heap operating on a standard LRU strategy. Oracle also began standardizing memory requirement sizes, which increases the likelihood of finding an acceptable size chunk. The subpools, multiple shared pool latches, and LRU strategy dramatically reduced shared pool memory management problems. If you have managed both an Oracle8i and an Oracle9i system, you probably experienced this change and noticed quite a difference.

The number of subpools on your system can be easily determined by either looking at the instance parameter _kghdsidx_count or by counting the number of rows in x$kghlu.