One of the easiest, most powerful, and most appropriate shared pool latching solutions is to simply add subpools, which will also add shared pool latches. The process is detailed in the earlier "From Hashing to Subpools" section.

This particular solution is very clean in that it requires minimal effort and we are not gaming Oracle's shared pool LRU algorithm. However, keep in mind that more subpools may require more shared pool memory, an instance restart is required for the instance parameter change to take affect, and Oracle reserves the right to not respect your recommendation.

As strange as this may sound, before subpools existed, increasing the shared pool size could eventually result in shared pool latch contention. Every algorithm is limited in capability and is designed to operate in specific situations. When the situation changes, the algorithm may not perform as desired. And don't forget that increasing a cache to support more activity will almost always require more CPU resources to manage. So, there will likely be a point of diminishing returns. Oracle's initial shared pool memory management algorithm worked fairly well up to a shared pool of around 600MB, but once it hit around 750MB, it was very common for DBAs to begin seeing significant shared pool latch contention.