CNDBA社区
今天早上回到办公室没多久就接到了新炬过来的电话，说我们的数据库服务器swap使用已经过了告警基准线，让我去看看应用是否还运行正常。于是赶紧登陆服务器查了一下swap的活动情况：
[cramer@zhzy-db01-p780:///]#lsps -s
Total Paging Space Percent Used
98304MB 35%
确实，swap空间使用了30多G，内存交换活跃，怕是数据库不能幸免于难了。于是再去生成一份AWR报告，看看整体上数据库各项的指标怎么样：
从系统负载上可以看出，数据库正经历一场灾难，各项统计指标都超出了平常的标准，对比平时的统计数据，read by other session 等待次数从平时的数千次暴增到240W+，平均等待时间从5ms 增加到21ms。gc buffer busy 与 db file scattered read 也是如此。
先来看看数据库的环境吧：
操作系统 AIX 6.1
操作系统物理内存 128G
数据库的配置如下：
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.5.0 - Productio
NLSRTL Version 10.2.0.5.0 - Production
SQL> show parameter sga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 90G
sga_target big integer 80G
SQL> show parameter pga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target big integer 10G
SQL>
操作系统频繁使用swap，原因基本是系统内存不够用了。从数据库的内存配置来看，128G总内存 ，配置给ORACLE 100g ，留给操作系统约30G，讲道理，应该是够用的了。
来看看oracle实际使用的内存：
select sum（pga_alloc_mem）/1024/1024/1024 Gb_Alloc from v$process ;
36.3
select sum(value)/1024/1024/1024 as Gb from v$sga ;
90
看出问题来了，实际使用内存数量为：90+ 36 = 126G，已经耗干了操作系统的所有内存，不使用swap才怪呢。很容易看出，问题的关键在于PGA这里，pga_aggregate_target 配置为10G，但是实际使用了36G，这是有可能的，pga_aggregate_target配置的值是个软限制，实际使用pga的使用是可以超过这个限制的。oracle会根据这个配置去限定每个服务进程使用的pga使用上限。假设在某一时段，有大量的进程都需要排序操作、大表hash join等等，从而从PGA里分走的都是一个上限值，那么就会发生上面的这种情况。
故障很容易定位到源头。应用系统有一个很频繁的查询，大概一分钟会被查询200次左右，该查询的逻辑相当的复杂，不过之前优化过，整体的开销已经不高了。昨晚因为一个需求，对查询做了一点点改动，仅仅是局部测试后就丢上生产了，结果在实际生产中，每一次查询都会有十几个大表进行hash连接。想一想，一分钟200次的查询，每次查询计算过会分走约1G的PGA空间，可想而知，结果会怎么样。
PS：应用配置了连接池，限制活动的连接数量为50个，因此PGA的消耗36G，数据基本吻合上面的估算了。
赶紧下线该应用并做优化，准备写故障报告，做好挨批的姿态。自己种的果，再苦也得自己咽了。。。。。。
Written In 11-Oct-16
版权声明：本文为博主原创文章，未经博主允许不得转载。
swap pga
