Oracle中的PGA监控报警分析(r11笔记第96天)

最近接到一个数据库报警，让我颇有些意外，这是一个PGA相关的报警。听起来感觉是应用端的资源调用出了问题。

报警内容大体如下：

报警内容: PGA Alarm on alltest这是一个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 但是看起来好像有些不大对劲，还有一个生疏的参数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; 结果看到最大进程怎么消耗如此之高，尽管是一个峰值而已。

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 5061.54467 [email protected] (IMCO)

这一下子让我有些懵，因为最大的进程竟然是IMCO,这是in memory选件的后台进程。

[[email protected] ~]$ ps -ef|grep 941这样一来问题就有些诡异了。

SQL> show sga通过SGA的输出可以看出，In-Memory占用了大概2G的内存空间。

而且这个参数比较让人纠结的就是无法动态修改,在实例初始化阶段才可以修改。

SQL> alter system set inmemory_size=1G;这样一个问题，难道是因为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变化曲线图，可发现是在逐步增长。

Oracle中的PGA监控报警分析(r11笔记第96天)

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

按照官方的解释，有3个途径可以改进这个问题。

1. Upgrade to 12.2, when available.目前来看，步骤2已经满足，只有重启一下，或者升级到12c了。

Oracle中的PGA监控报警分析(r11笔记第96天)

相关推荐