785
無微不至：調整_lm_cache_res_cleanup解決Shared Pool 的4031問題
李真旭（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的必備素質
本文出自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 18:03:58