<< 返回文章列表

数据恢复| 无微不至:调整_lm_cache_res_cleanup解决Shared Pool 的4031问题

2017年12月25日
李真旭
2315

【云和恩墨,提供7*24最专业的数据恢复(Oracle,MySQL,SQL server)服务,致力于为您的数据库系统做最后一道安全防护!服务热线:010-59007017-7030】数据恢复|数据库运维|性能优化|安全保障|Oracle培训|MySQL培训


前不久某客户的一套核心数据库(10.2.0.4.12),据说每间隔一段时间就必须重启,因为会报ORA-04031 错误。

查询发现 shared pool 差不多 5G 的样子,其实 ges resource 消耗了差不多 3.5G shared pool 内存,也确实有些离谱了。

image.png

我们可以看到,ges resource 消耗的内存确实非常高。那么这里为什么 ges resource 消耗的内存这么高呢?

通过检查 v$resource_limit 发现存在有些异常,如下所示:

image.png

我们可以发现,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 的内存消耗得到了有效控制:

image.png

在未调整参数之前,重启实例1天,ges resource 就超过 300M了,然后逐渐攀升,直至出现问题。

备注:  bug 9026008,bug 10042937 跟该参数有关系,影响版本为11.1,11.2部分版本,大家可以阅读下。

总结:Oracle数据库的精细程度往往超越了大家的经验,几乎每一个微小的功能都存在着控制参数,遇到问题时,仔细分析,深入细节,最后从源头解决问题,是Oracle DBA的必备素质。