Oracle中的PGA監控報警分析(r11筆記第96天)
最近接到一個數據庫報警，讓我頗有些意外，這是一個PGA相關的報警。聽起來感覺是應用端的資源調用出了問題。
報警內容大體如下：
報警內容: PGA Alarm on alltest
------------------------------------
報警級別: PROBLEM
------------------------------------
監控專案: PGA：6118.6
這是一個12cR1的環境，是一套測試環境，確切的說是多套環境整合後的一套大的測試環境，裡面含有近8個PDB，也就是之前的多個測試環境整合而來。
所以我就簡單進行了排查，首先這個報警是怎麼來的，是在Orabbix配置的監控項。
在Zabbix中檢視，可以看到這個報警的相關配置。
({Template_Oracle_OLTP:pga.last(0)}*100/{Template_Oracle_OLTP:pga_aggregate_target.last(0)})>95
也就意味著PGA的使用率達到了95%以上的時候就觸發報警，這裡涉及兩個監控項pga和pga_aggregate_target。
相關的SQL如下，監控項的SQL在Orabbix中是按照 【監控項】.Query的格式展現的。
pga_aggregate_target.Query=select to_char(decode( unit,'bytes', value/1024/1024, value),'999999999.9') value from V$PGASTAT where name in 'aggregate PGA target parameter'
pga.Query=select to_char(decode( unit,'bytes', value/1024/1024, value),'999999999.9') c 對於這個問題，檢視資料庫引數，目前的pga設定是6GSQL> show parameter pga
NAME TYPE VALUE
----------------------- ----------- --------
pga_aggregate_limit big integer 12880M
pga_aggregate_target big integer 6440M但是看起來好像有些不大對勁，還有一個生疏的引數pga_aggregate_limit,這個引數是幹什麼的，其實這是12c中引入的一個引數，對於pga_aggregate_target的補充。怎麼理解容易一些呢，pga_aggregate_target是一個基線值，比如設定為6G,如果PGA使用超過了6G還是很難做到管控，就可能導致一些hang，無響應的問題，這個問題在12c中是考慮引進了引數pga_aggregate_limit來完善的，也就是這個引數的值就是一個最終的大小，絕對不能超過。這個引數輸出中，目前的limit值預設給設定為了12G,而原本設定的target值為6G.
目前的報警是PGA使用超過了閾值，那什麼樣的應用會導致如此的PGA使用情況呢，這個讓我有些疑惑。一般來說，單個程序的PGA佔用量其實不大，多點也就幾十MB而已。當然為了先儘快修復這個問題，我把PGA target的值改為了7G.
然後我們可以直接這樣嘗試定位一下問題，看看佔用PGA最多的程序是哪個，依次來排除。
SQL> select max(pga_max_mem/1024/1024) from v$process;
MAX(PGA_MAX_MEM/1024/1024)
--------------------------
7989.28072
結果看到最大程序怎麼消耗如此之高，儘管是一個峰值而已。
SQL> select * from (select spid,pga_max_mem/1024/1024,pga_alloc_mem/1024/1024,pga_used_mem/1024/1024,program from v$process order by pga_used_mem desc) where rownum<10;
輸出的資料如下：
SPID PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PROGRAM
--------- --------------------- ----------------------- -----------
941 7989. 7989.4 5061.54467 [email protected] (IMCO)
925 132 39.851 37.1080208 [email protected] (ARC0)
931 116 38.788 37.0642586 [email protected] (ARC3)
937 36.96 33.093 31.872448 [email protected] (W000)
9201 37.28 31.968 31.7101784 [email protected] (W00C)
1491 32.53 32.468 31.6490288 [email protected] (W001)
1327 33.90 31.968 31.6361275 [email protected] (W002)
8181 32.53 31.843 31.5896568 [email protected] (W009)
3510 32.78 32.093 31.5785789 [email protected] (W005)
這一下子讓我有些懵，因為最大的程序竟然是IMCO,這是in memory選件的後臺程序。
[oracle@teststd ~]$ ps -ef|grep 941
oracle 941 1 0 2016 ? 07:45:21 ora_imco_testdb
這樣一來問題就有些詭異了。
SQL> show sga
Total System Global Area 2.0267E+10 bytes
Fixed Size 3721272 bytes
Variable Size 1.1409E+10 bytes
Database Buffers 6643777536 bytes
Redo Buffers 63385600 bytes
In-Memory Area 2147483648 bytes
通過SGA的輸出可以看出，In-Memory佔用了大概2G的記憶體空間。
而且這個引數比較讓人糾結的就是無法動態修改,在例項初始化階段才可以修改。
SQL> alter system set inmemory_size=1G;
alter system set inmemory_size=1G
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-02095: specified initialization parameter cannot be modified
這樣一個問題，難道是因為imco的特殊性導致了PGA的佔用量大步提升，也被歸納算入了。實際上in memory自啟用後就沒有正式啟用，沒有任何表的資料放在IMO裡，所以也排除了IMO的一些異常情況。還有一個驗證的方式就是通過Data Guard來對比補充，結果檢視備庫的imco程序情況，壓根誒呦發現什麼問題。還有一個思路那就是對比其他的12c環境，是否也存在類似的問題，還有一套近期搭建的12cR2的環境，也啟用了IMO，但是IMCO程序的PGA佔用量很低。這也符合了一個常規的想法，那麼這個問題是怎麼造成的呢，我的一個直觀感受就是一個bug.
這個想法在MOS上得到了一個基本的印證，可以參考
IMCO Background Process Keeps Growing in Memory Usage over Time (Doc ID 2106806.1) 這裡有一個問題需要確認，那就是IMCO的程序佔用情況是逐步的增長還是一開始就很高。
這一點上完全可以通過Zabbix的監控圖得到。
檢視近一年的PGA變化曲線圖，可發現是在逐步增長。
所以和MOS裡面的那個bug吻合度很高。
按照官方的解釋，有3個途徑可以改進這個問題。
1. Upgrade to 12.2, when available.
2. Apply the 12.1.0.2.10DBBP patch (or if you apply PSUs instead of DBBPs, apply the 12.1.0.2.160119DBPSU).
3. Apply interim Patch 19159120 for your RDBMS version and OS.
目前來看，步驟2已經滿足，只有重啟一下，或者升級到12c了。