Oracle 12c因bug導致ORA-04031問題處理過程

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

為了及時共享行業案例，通告共性問題，達成知識共享和提前預防，我們整理和編輯了《雲和恩墨技術通訊》（8月刊），通過對過去一段時間的知識回顧和故障歸納，以期提供有價值的資訊供大家參考。
同時，我們也希望能夠將熱點事件、新的產品特性及其他有價值的資訊聚集起來，為您提供具有前瞻性的支援資訊，保持對於當前最新的資料庫新聞和事件的瞭解，其中包括重要資料庫產品釋出、警報、更新、新版本、補丁等。

本期目錄：

• 新聞：2019年8月資料庫流行度排行

• 警示：12.1.2.0與11.2.0.4通過DB Link查詢觸發BUG 17890099

• 警示：Oracle 12c因bug導致ORA-04031

• 警示：ORA-00600 2252 錯誤正在SCN問題下不斷爆發

• 經驗：12c多租戶例項意外當機處理

• 經驗：記一次tuxedo crash的故障處理

• 問題：故障排除之enq:TX - index contention等待事件

• 公告：墨天輪DBASK技術專家邀請函

搶先下載：https://www.modb.pro/doc/572（複製連結瀏覽器中開啟，或者點選“閱讀原文”）

部分精選-Oracle 12c因bug導致ORA-04031（姜勁鬆）

ORA-04031這個錯誤，幾乎每一個專業的DBA都遇到過。這是一個相當嚴重的錯誤，Oracle程式在向SGA申請記憶體時，如果申請失敗，則會丟擲這個錯誤，大部分情況下是在向SGA中的shared pool申請記憶體時失敗。在Oracle 12.1.0.2及以後版本中，有可能是因為觸發了bug 26405036  Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool導致資料庫shared pool記憶體爆滿引發ORA-04031報錯，這個bug在19.1版本上已經修復，針對12.2的版本需打上相應的補丁進行修復。

問題描述

在7月17日上午11時10左右，某客戶收到告警簡訊，提示資料庫（12.2的三節點RAC環境）的2號節點當機，當即登陸該節點進行檢視，發現資料庫狀態正常，但日誌裡出現大量的ORA-04031報錯，提示無法分配shared_pool，手動執行shared pool重新整理指令碼進行重新整理，重新整理後shared pool使用率仍然為70%左右。此時有業務反饋資料庫節點3無法連線，客戶決定對節點3進行重啟，重啟後恢復正常，經過後續觀察，節點2 的ORA-04031報錯也再沒有出現。

問題分析

檢視當時節點二的告警日誌，發現日誌中丟擲ORA-04031報錯資訊

節點三10:49就開始報ORA-04031,直到11:51被手動停止例項

所以故障原因最早是節點三例項導致的，檢視4031 的dump trace檔案，在heapdump發現ges resource dynamic/ges enqueues異常高：

檢視這2個pool的變化趨勢，發現ges resource dynamic/ges enqueues一直在持續增長：

1. 故障前ges enqueues達到17GB，重啟後恢復為3.8GB，但後續還是會增長；
2. 故障前ges resource dynamic高達22GB(2個子池)，重啟後4.8GB，後續0718 06:00新增1個1.2GB子池並持續增長。

問題解決

根據該故障現象，查詢MOS發現：Bug 26405036  Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool。

且該bug出現的資料庫版本和本庫匹配(本庫版本Linux 12.2.0.1，fix在19.1.0才包含）,現象也匹配。

建議解決措施：
1. 針對12.2版本，通過應用補丁Patch 26405036: VERY HIGH "GES ENQUEUES" ON THE SHARED POOL得到解決。
2. 針對12.2版本，workaround可以在出現問題時臨時使用如下命令清理記憶體(後續還是會增長)：

SQL> oradebug setmypid
SQL> oradebug lkdebug -m reconfig lkdebug

3. 針對12.1版本，建議重啟例項。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31556440/viewspace-2654771/，如需轉載，請註明出處，否則將追究法律責任。