In oracle, the shared Pool problem is solved by adjusting _ lm_cache_res_cleanup.

Not long ago a customer's core database (10.2.0.4.12), it is said that each interval must be restarted, because the ORA-04031 error will be reported. The query found that the shared pool looked like 5 GB. In fact, the ges resource consumed almost 3.5 GB of shared pool memory, which is indeed somewhat outrageous.

SQL> c/gcs/ges
1 * select * from v $ sgastat where name like 'ges %'
SQL>/
 
We can see that the memory consumed by ges resource is indeed very high. So why is the memory consumed by ges resource so high?
Check v $ resource_limit to find some exceptions, as shown below:

RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
---------------------------------------------------------------------------------------
Ges_procs 181 439 1001 1001
Ges_ress 0 0 27462 UNLIMITED
Ges_locks 0 0 40358 UNLIMITED
Ges_cache_ress 8559179 14625461 0 UNLIMITED
Ges_reg_msgs 243 898 2750 UNLIMITED
Ges_big_msgs 41 35280 1934 UNLIMITED
Ges_rsv_msgs 0 0 1000 1000
 
SQL> select startup_time from v $ instance;
 
STARTUP_TIME
-------------------
05:02:04

We can find that the max and current of ges_cache_ress are large. Big is beyond imagination. From the perspective of the phenomenon, it can be roughly determined that the ges resource in the shared pool is not collected in time, resulting in a large memory occupied by the ges resource.
I have a question in my mind: is there any implicit parameter in Oracle to control this resource recovery mechanism? We know that Oracle usually does this, and uses implicit parameters to control a function or mechanism.
Found 2 related bugs, it is indeed possible to have a high memory consumption of ges resource, and finally generate a ora-04031 error.
This document mentions the parameter _ lm_cache_res_cleanup. You can adjust this parameter to recycle the ges resource in this table. This situation may be avoided.

If the method is easy to use, you have to try it before knowing it. Tell the customer to make adjustments, and then observe for a few days, it seems that the memory consumption of ges resource has been effectively controlled:

SQL> select * from v $ sgastat where name like '% ges res % ';
 
POOL NAME BYTES
---------------------------------------------------------------
Shared pool ges resource hash seq tab 32768
Shared pool ges res mastership bucket 4096
Shared pool ges resource pools 1984
Shared pool ges reserved msg buffers 8240008
Shared pool ges resource 215312592
Shared pool ges resource hash table 1441792
 
6 rows selected.
 
SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24: mi: SS ';
 
Session altered.
 
SQL> select startup_time from v $ instance;
 
STARTUP_TIME
-------------------
23:08:27
 
SQL> select sysdate from dual;
 
SYSDATE
-------------------
10:24:17
Some may say that it may not be visible in just a few days? In fact, it takes only one day to restart the instance before the customer has not adjusted the number of days, and the ges resource exceeds MB.
Note: bug 9026008 and bug 10042937 are related to this parameter. The affected versions include 11.1 and 11.2. You can read this article.