最近接到一個數(shù)據(jù)庫報警，讓我頗有些意外，這是一個PGA相關(guān)的報警。聽起來感覺是應(yīng)用端的資源調(diào)用出了問題。

報警內(nèi)容大體如下：

報警內(nèi)容: PGA Alarm on alltest

------------------------------------報警級別: PROBLEM

------------------------------------監(jiān)控項目: PGA：6118.6這是一個12cR1的環(huán)境，是一套測試環(huán)境，確切的說是多套環(huán)境整合后的一套大的測試環(huán)境，里面含有近8個PDB，也就是之前的多個測試環(huán)境整合而來。

所以我就簡單進(jìn)行了排查，首先這個報警是怎么來的，是在Orabbix配置的監(jiān)控項。

在Zabbix中查看，可以看到這個報警的相關(guān)配置。

({Template_Oracle_OLTP:pga.last(0)}*100/{Template_Oracle_OLTP:pga_aggregate_target.last(0)})>95也就意味著PGA的使用率達(dá)到了95%以上的時候就觸發(fā)報警，這里涉及兩個監(jiān)控項pga和pga_aggregate_target。

相關(guān)的SQL如下，監(jiān)控項的SQL在Orabbix中是按照 【監(jiān)控項】.Query的格式展現(xiàn)的。

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對于這個問題，查看數(shù)據(jù)庫參數(shù)，目前的pga設(shè)置是6GSQL> show parameter pga

NAME?????? ? ? ? ? ?TYPE??? ? VALUE

----------------------- ----------- --------

pga_aggregate_limit???? big integer 12880M

pga_aggregate_target??? big integer 6440M但是看起來好像有些不大對勁，還有一個生疏的參數(shù)pga_aggregate_limit,這個參數(shù)是干什么的，其實這是12c中引入的一個參數(shù)，對于pga_aggregate_target的補充。怎么理解容易一些呢，pga_aggregate_target是一個基線值，比如設(shè)置為6G,如果PGA使用超過了6G還是很難做到管控，就可能導(dǎo)致一些hang，無響應(yīng)的問題，這個問題在12c中是考慮引進(jìn)了參數(shù)pga_aggregate_limit來完善的，也就是這個參數(shù)的值就是一個最終的大小，絕對不能超過。這個參數(shù)輸出中，目前的limit值默認(rèn)給設(shè)置為了12G,而原本設(shè)置的target值為6G.

目前的報警是PGA使用超過了閾值，那什么樣的應(yīng)用會導(dǎo)致如此的PGA使用情況呢，這個讓我有些疑惑。一般來說，單個進(jìn)程的PGA占用量其實不大，多點也就幾十MB而已。當(dāng)然為了先盡快修復(fù)這個問題，我把PGA target的值改為了7G.

然后我們可以直接這樣嘗試定位一下問題，看看占用PGA最多的進(jìn)程是哪個，依次來排除。

SQL>? select max(pga_max_mem/1024/1024) from v$process;

MAX(PGA_MAX_MEM/1024/1024)

--------------------------

7989.28072結(jié)果看到最大進(jìn)程怎么消耗如此之高，盡管是一個峰值而已。

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;

輸出的數(shù)據(jù)如下：

SPID?? PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PROGRAM

--------- --------------------- ----------------------- -----------

941??? 7989.??? 7989.4??5061.54467 oracle@teststd.test.com (IMCO)

925??? 132??? 39.851?? 37.1080208 oracle@teststd.test.com (ARC0)

931??? 116??? 38.788?? 37.0642586 oracle@teststd.test.com (ARC3)

937??? 36.96??? 33.093??? 31.872448 oracle@teststd.test.com (W000)

9201?? 37.28??? 31.968?? 31.7101784 oracle@teststd.test.com (W00C)

1491?? 32.53??? 32.468?? 31.6490288 oracle@teststd.test.com (W001)

1327?? 33.90??? 31.968?? 31.6361275 oracle@teststd.test.com (W002)

8181?? 32.53??? 31.843?? 31.5896568 oracle@teststd.test.com (W009)

3510?? 32.78??? 32.093?? 31.5785789 oracle@teststd.test.com (W005)

這一下子讓我有些懵，因為最大的進(jìn)程竟然是IMCO,這是in memory選件的后臺進(jìn)程。

[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的內(nèi)存空間。

而且這個參數(shù)比較讓人糾結(jié)的就是無法動態(tài)修改,在實例初始化階段才可以修改。

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的特殊性導(dǎo)致了PGA的占用量大步提升，也被歸納算入了。實際上in memory自啟用后就沒有正式啟用，沒有任何表的數(shù)據(jù)放在IMO里，所以也排除了IMO的一些異常情況。還有一個驗證的方式就是通過Data Guard來對比補充，結(jié)果查看備庫的imco進(jìn)程情況，壓根誒呦發(fā)現(xiàn)什么問題。還有一個思路那就是對比其他的12c環(huán)境，是否也存在類似的問題，還有一套近期搭建的12cR2的環(huán)境，也啟用了IMO，但是IMCO進(jìn)程的PGA占用量很低。這也符合了一個常規(guī)的想法，那么這個問題是怎么造成的呢，我的一個直觀感受就是一個bug.

這個想法在MOS上得到了一個基本的印證，可以參考

IMCO Background Process Keeps Growing in Memory Usage over Time (Doc ID 2106806.1)這里有一個問題需要確認(rèn)，那就是IMCO的進(jìn)程占用情況是逐步的增長還是一開始就很高。

這一點上完全可以通過Zabbix的監(jiān)控圖得到。

查看近一年的PGA變化曲線圖，可發(fā)現(xiàn)是在逐步增長。

所以和MOS里面的那個bug吻合度很高。

按照官方的解釋，有3個途徑可以改進(jìn)這個問題。

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已經(jīng)滿足，只有重啟一下，或者升級到12c了。

總結(jié)

以上是生活随笔為你收集整理的oracle错误1327,Oracle中的PGA监控报警分析(r11笔记第97天)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。