门户网站app开发,中国十大广告公司排名,网站 cms,苏州品牌网站设计最近接到一个数据库报警#xff0c;让我颇有些意外#xff0c;这是一个PGA相关的报警。听起来感觉是应用端的资源调用出了问题。报警内容大体如下#xff1a;报警内容: PGA Alarm on alltest------------------------------------报警级别: PROBLEM------------------------…最近接到一个数据库报警让我颇有些意外这是一个PGA相关的报警。听起来感觉是应用端的资源调用出了问题。报警内容大体如下报警内容: PGA Alarm on alltest------------------------------------报警级别: PROBLEM------------------------------------监控项目: PGA6118.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.Queryselectto_char(decode( unit,bytes, value/1024/1024, value),999999999.9)value from V$PGASTAT where name in aggregate PGA target parameterpga.Queryselectto_char(decode( unit,bytes, value/1024/1024, value),999999999.9)c对于这个问题查看数据库参数目前的pga设置是6GSQL show parameter pgaNAME TYPE VALUE----------------------- ----------- --------pga_aggregate_limit big integer 12880Mpga_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(selectspid,pga_max_mem/1024/1024,pga_alloc_mem/1024/1024,pga_used_mem/1024/1024,programfrom v$process order by pga_used_mem desc) where rownum10;输出的数据如下SPID PGA_MAX_MEM PGA_ALLOC_MEM PGA_USED_MEM PROGRAM--------- --------------------- ----------------------- -----------941 7989. 7989.4 5061.54467 oracleteststd.test.com (IMCO)925 132 39.851 37.1080208 oracleteststd.test.com (ARC0)931 116 38.788 37.0642586 oracleteststd.test.com (ARC3)937 36.96 33.093 31.872448 oracleteststd.test.com (W000)9201 37.28 31.968 31.7101784 oracleteststd.test.com (W00C)1491 32.53 32.468 31.6490288 oracleteststd.test.com (W001)1327 33.90 31.968 31.6361275 oracleteststd.test.com (W002)8181 32.53 31.843 31.5896568 oracleteststd.test.com (W009)3510 32.78 32.093 31.5785789 oracleteststd.test.com (W005)这一下子让我有些懵因为最大的进程竟然是IMCO,这是in memory选件的后台进程。[oracleteststd ~]$ ps -ef|grep 941oracle 941 1 0 2016 ? 07:45:21 ora_imco_testdb这样一来问题就有些诡异了。SQL show sgaTotal System Global Area 2.0267E10 bytesFixed Size 3721272 bytesVariable Size 1.1409E10 bytesDatabase Buffers 6643777536 bytesRedo Buffers 63385600 bytesIn-Memory Area 2147483648 bytes通过SGA的输出可以看出In-Memory占用了大概2G的内存空间。而且这个参数比较让人纠结的就是无法动态修改,在实例初始化阶段才可以修改。SQL alter system set inmemory_size1G;alter system set inmemory_size1G*ERROR at line 1:ORA-02097: parameter cannot be modified because specified value is invalidORA-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了。
