歡迎光臨
每天分享高質量文章

雲和恩墨技術通訊: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

已同步到看一看
赞(0)

分享創造快樂