前言
){kind=link}
文章的最后将从运维与开发层面提炼共性的风险提示和注意事项，希望能对大家有所帮助和启发！## 1.问题来了
系统环境基本信息如下
## 2.分析过程
##){kind=link}
2.1 数据库服务器内存配置
){kind=link}
可以看到，数据库服务器配置了24G内存，但是free非小，只有22248*4k=86M.Topas中可以看到，计算内存占了96%，换页空间使用率高达40%。说明数据库服务器已经由于内存不足发生了大量换页，系统已经处于非常危险的状态，如果不及时处理，将可能出现宕机的情况。解决问题前，可通过定期逐个重启WAS或者数据库服务器来临时解决。
){kind=link}
可以看到，数据库实际占用的内存大小为SGA+PGA+所有服务进程在操作系统级的内存消耗，即10G + 9.1g + 500 * 4 =21G左右,机器内存是24G，那么出现内存紧张、换页就是必然的了！### 2.2 确认PGA内存泄漏
){kind=link}
### 2.3 确认内存泄漏的进程信息
###){kind=link}
){kind=link}
){kind=link}
){kind=link}
取出package pkg_xx的代码，做进一步分析。### 2.4 对PGA内存占用情况进一步分解
){kind=link}
){kind=link}
){kind=link}
通过分类汇总和计算，占用最大的是“pmuccst:adt/recored”和”pl/sql vc2“，分别是220M和80M，这两个就是存储PL/SQL的集合、数组等内容，之前的分析得到验证。### 2.5 为什么非活动会话不释放PGA且PGA随时间增长
){kind=link}
在调用PKG_XX. Sp_xx这个存储过程的其他存储过程/packgae处，对数组p_target.ret进行重新初始化，而不是让数组无限制扩展下去。### 2.6 重现问题的测试案例
){kind=link}
){kind=link}
){kind=link}
){kind=link}
### 2.7 真相大白
###){kind=link}
){kind=link}
即如果传入的数组p_target.ret不为空，那么将为数组p_target.ret不断增加元素的个数（对应p_target.ret.EXTEND处代码），并为每个元素赋值(即p_target.ret(p_target.ret.COUNT) := v_ret)
在项目组按照建议修改程序后，问题不再发生。### 2.8 风险提示
){kind=link}