李真旭（Roger）

云和恩墨西北區(qū)技術(shù)總監(jiān)

Oracle ACE, ACOUG 核心會員

前不久某客戶的一套核心數(shù)據(jù)庫(10.2.0.4.12)，據(jù)說每間隔一段時間就必須重啟，因為會報ORA-04031 錯誤。

查詢發(fā)現(xiàn) shared pool 差不多 5G 的樣子，其實 ges resource 消耗了差不多 3.5G shared pool 內(nèi)存，也確實有些離譜了。

我們可以看到，ges resource 消耗的內(nèi)存確實非常高。那么這里為什么 ges resource 消耗的內(nèi)存這么高呢？

通過檢查 v$resource_limit 發(fā)現(xiàn)存在有些異常，如下所示：

我們可以發(fā)現(xiàn)，ges_cache_ress 的 max 和 current 都很大，大的超乎想象。從現(xiàn)象來看，可以大致判斷是 shared pool 中 cache 的 ges resource 沒有及時回收，導致 ges resource占據(jù)的內(nèi)存比較大。

想到這里，我心中產(chǎn)生了一個疑問，是否 Oracle 有相關(guān)隱含參數(shù)來控制這個資源回收的機制呢？我們知道 Oracle 通常都是這么干的，通過隱含參數(shù)來控制某項功能或機制。

搜下發(fā)現(xiàn)了2個相關(guān)的 bug，確實可能出現(xiàn) ges resource 消耗內(nèi)存很高的情況，最后產(chǎn)生ora-04031錯誤。

其中文檔中提到了一個參數(shù) _lm_cache_res_cleanup；通過調(diào)整該參數(shù)，來該表 ges resource 的回收機制；有可能避免這個情況。

方法好用不，要試試才知道，果斷告知客戶進行調(diào)整，然后觀察幾天后，發(fā)現(xiàn) ges resource 的內(nèi)存消耗得到了有效控制：

在未調(diào)整參數(shù)之前，重啟實例1天，ges resource 就超過 300M了，然后逐漸攀升，直至出現(xiàn)問題。

備注： ?bug 9026008，bug 10042937 跟該參數(shù)有關(guān)系，影響版本為11.1，11.2部分版本，大家可以閱讀下。

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

本文出自數(shù)據(jù)和云公眾號，原文鏈接

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。