love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

通过调整_lm_cache_res_cleanup解决shared Pool问题

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: 通过调整_lm_cache_res_cleanup解决shared Pool问题

前不久某客户的一套核心数据库(10.2.0.4.12),据说每间隔一段时间就必须重启,因为会报ORA-04031错误。查询发现shared pool差不多5G的样子,其实ges resource消耗了差不多3.5G shared pool 内存,也确实有些离谱了。

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

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

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

有些人可能会说,才几天可能看不出来吧?实际上,之前客未调整之前,重启实例才1天,ges resource就超过300M了。

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

    分享到:
18180207355
加Q咨询