雲和恩墨技術通訊：Oracle AMM自動記憶體管理引起資料庫阻塞

各位親愛的使用者/讀者朋友們：

為了及時共享行業案例，通告共性問題，達成知識共享和提前預防，我們整理和編輯了《雲和恩墨技術通訊》（4月刊），透過對過去一段時間的知識回顧和故障歸納，以期提供有價值的資訊供大家參考。

同時，我們也希望能夠將熱點事件、新的產品特性及其他有價值的資訊聚集起來，為您提供具有前瞻性的支援資訊，保持對於當前最新的資料庫新聞和事件的了解，其中包括重要資料庫產品釋出、警報、更新、新版本、補丁等。

本期目錄：

• 新聞：2019年4月份資料庫流行度排行版
• 經驗：低效應用指令碼
• 經驗：AMM自動記憶體管理引起資料庫阻塞
• 頻發：記DFS LOCK HANDLE等待的一次故障處理
• 頻發：不合理的序列CACHE值造成的效能故障
• 警示：IBATIS 2.3.0同步鎖bug導致大量STUCK執行緒
• 預警：ORACLE近期關註之SCN問題
• 問題：GES_PROCS資源限制導致ORA-00020
• 問題：ENQ: TX – ROW LOCK CONTENTIION
• 公告：墨天輪正式上線DB-RANK

部分精選-AMM自動記憶體管理引起資料庫阻塞

Oracle 11g推出了自動記憶體管理（AMM）新特性，該特性引入後，雖然減輕了DBA手動設定共享記憶體的負擔，但經常出現在shared pool和buffer cache之間發生頻繁shrink/grow操作的現象，特別是shared pool的shrink操作，在一些高併發環境下，會刷出一批共享池物件，並間歇性持有shared pool latch,library cache lock等共享池的閂鎖，從而引發資料庫效能問題的風險，極端情況下，會導致資料庫效能短時間內極速下降。

 

在雲和恩墨的資料庫最佳實踐中，對於高併發的資料庫，都建議關閉自動記憶體管理（AMM）新特性，而是採用固定的shared pool和buffer cache記憶體設定。在此我們分享一個近期的客戶案例，供大家參考。 

 

問題描述

 

當Oracle資料庫使用自動記憶體管理（AMM）時，shared pool和buffer cache之間發生頻繁的記憶體shrink/grow時有可能會引起資料庫大量遊標失效，隨後的解析會導致大量library cache及cursor等待事件。近期在某資料庫碰到這種情況，具體表現為故障時間段內資料庫會話激增，並出現大量cursor解析類等待事件。

 

 

並且，出現的主要等待事件如下圖：

 

 

這裡，SGA: allocation forcing component growth等待，並伴隨大量的library cache load/lock、cursor: mutex X/S等事件。SGA: allocation forcing component growth是記憶體自動增長的等待，其他等待事件主要為解析相關。大量的會話遊標解析等待，但是並無明確阻塞源說明遊標類等待是由於再次的SQL硬解析導致，這個很可能和自動記憶體管理有關。

 

同時，在此期間，buffer cache和shared pool均發生了快速的伸縮抖動。

 

 

可以看到，在19:09分時，shared pool記憶體從148,48M降低到14,336M，降低了500M, 為了騰出這500M，在高併發環境中，就會需要刷出一批共享池物件，並持有各種共享池的閂/鎖，從而導致了效能問題。

 

問題原因

本庫採用自動記憶體管理(AMM)，在故障期間shared pool和buffer cache之間的記憶體shrink/grow,導致大量遊標失效，隨後的解析導致大量library cache及cursor等待事件。

 

問題建議

關閉自動SGA記憶體管理，sga_target=0，並根據環境設定適當的db_cache_size及shared_pool_size

 

下載連結：https://cs.enmotech.com/docDownload/2789