今天早上回到办公室没多久就接到了新炬过来的电话，说我们的数据库服务器swap使用已经过了告警基准线，让我去看看应用是否还运行正常。于是赶紧登陆服务器查了一下swap的活动情况：

[cramer@zhzy-db01-p780:///]#lsps -s

Total Paging Space   Percent Used

98304MB               35%

确实，swap空间使用了30多G，内存交换活跃，怕是数据库不能幸免于难了。于是再去生成一份AWR报告，看看整体上数据库各项的指标怎么样：https://www.cndba.cn/cndba/arealman/article/381

https://www.cndba.cn/cndba/arealman/article/381

从系统负载上可以看出，数据库正经历一场灾难，各项统计指标都超出了平常的标准，对比平时的统计数据，read by other session 等待次数从平时的数千次暴增到240W+，平均等待时间从5ms 增加到21ms。gc buffer busy 与 db file scattered read 也是如此。https://www.cndba.cn/cndba/arealman/article/381

https://www.cndba.cn/cndba/arealman/article/381

先来看看数据库的环境吧：

操作系统 AIX 6.1

操作系统物理内存 128G

https://www.cndba.cn/cndba/arealman/article/381https://www.cndba.cn/cndba/arealman/article/381

数据库的配置如下：

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

CORE10.2.0.5.0Production

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，数据基本吻合上面的估算了。https://www.cndba.cn/cndba/arealman/article/381

https://www.cndba.cn/cndba/arealman/article/381https://www.cndba.cn/cndba/arealman/article/381

赶紧下线该应用并做优化，准备写故障报告，做好挨批的姿态。自己种的果，再苦也得自己咽了。。。。。。

Written In 11-Oct-16

https://www.cndba.cn/cndba/arealman/article/381

版权声明：本文为博主原创文章，未经博主允许不得转载。

swap pga