问题描述
前不久某客户的一套核心数据库(10.2.0.4.12),据说每间隔一段时间就必须重启，因为会报ORA-04031错误。查询发现shared pool差不多5G的样子，其实ges resource消耗了差不多3.5G shared pool 内存，也确实有些离谱了。
SQL> c/gcs/ges 1* select * from v$sgastat where name like 'ges%' SQL> / POOL NAME BYTES ------------ ------------------------------- ---------- shared pool ges big msg p 461440 shared pool ges resource hash seq tab 32768 shared pool ges shared global area 23928 shared pool ges regular msg buffers 1254008 shared pool ges enqueue multiple free 1280 shared pool ges res mastership bucket 4096 shared pool ges deadlock xid freelist 11264 shared pool ges resource pools 1984 shared pool ges recovery domain table 176 shared pool ges reserved msg buffers 8240008 shared pool ges big msg buffers 15936168 shared pool ges process array 1273272 shared pool ges enqueue max. usage pe 32 shared pool ges lmd process descripto 2760 shared pool ges process hash table 44000 shared pool ges enqueue cur. usage pe 32 shared pool ges ipc instance maps 384 shared pool ges lms process descripto 5520 shared pool ges resource 3696886168 shared pool ges deadlock xid hash tab 17800 shared pool ges resource hash table 1441792 shared pool ges scan queue array 176
专家解答
我们可以看到，ges resource消耗的内存确实非常高。那么这里为什么ges resource 消耗的内存这么高呢？
通过检查v$resource_limit发现存在有些异常，如下所示：
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 ------------------- 2015-10-26 05:02:04
我们可以发现，ges_cache_ress 的max 和 current 都很大。大的超乎想象。从现象来看，可以大致判断是shared pool中cache的 ges resource没有及时回收，导致ges resource占据的内存比较大。
想到这里，我心中产生了一个疑问，是否Oracle 有相关隐含参数来控制这个资源回收的机制呢？我们知道Oracle 通常都是这么干的，通过隐含参数来控制某项功能或机制。
搜下发现了2个相关的bug，确实可能出现ges resource 消耗内存很高的情况，最后产生ora-04031错误。
其中文档中提到了一个参数_lm_cache_res_cleanup；通过调整该参数，来该表ges resource的回收机制；有可能避免这个情况。
方法好用不，要试试才知道，果断告知客户进行调整，然后观察几天后，发现似乎ges resource的内存消耗得到了有效控制：
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 ------------------- 2016-01-28 23:08:27 SQL> select sysdate from dual; SYSDATE ------------------- 2016-02-03 10:24:17
有些人可能会说，才几天可能看不出来吧？实际上，之前客未调整之前，重启实例才1天，ges resource就超过300M了。
备注： bug 9026008，bug 10042937 跟该参数有关系，影响版本为11.1，11.2部分版本，大家可以阅读下。
