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.

To illustrate my point, back in Oracle8i days, while speaking to about 300 Oracle E-Business Suite DBAs, I took a survey. I asked the DBAs to raise their hand if they kept increasing shared pool memory to reduce 4031 errors, but while the 4031 errors decreased, they also saw a significant increase in shared pool latch contention. To the surprise of their colleagues, about one-third of all the DBAs raised their hands! Upon further questioning, we learned that for the Oracle Applications (as they were called then), the point of diminishing returns was around a 700MB shared pool.