李真旭（Roger）

云和恩墨西北區技術總監

Oracle ACE, ACOUG 核心會員

前不久某客戶的一套核心數據庫(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部分版本，大家可以閱讀下。

總結：Oracle數據庫的精細程度往往超越了大家的經驗，幾乎每一個微小的功能都存在著控制參數，遇到問題時，仔細分析，深入細節，最后從源頭解決問題，是Oracle DBA的必備素質

本文出自數據和云公眾號，原文鏈接

總結

以上是生活随笔為你收集整理的无微不至：调整_lm_cache_res_cleanup解决Shared Pool 的4031问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。