公众号：杨建荣的学习笔记 · 作者：r3笔记第13天 · 发布：2014-10-02 22:59:39 · 原文链接

在生产环境中，作为dba需要对系统的负载有一个很清晰的认识。能够在很快的时间内能够发现系统潜在的问题，并且及时定位问题，高效的响应和处理问题。
比如说对于生产环境的session leak问题，这个部分是awr都很难捕捉到的信息，如果问题比较隐蔽，连ash也很难定位。
比如说在早上9点的时候某个程序出现了session leak的问题，有些程序的处理不能及时的关闭连接，到时连接数急剧增加，但是因为这个过程中，那些连接到数据库session没有再处理数据，就变成了Inactivie了，这部分信息ash也是很难捕捉到的。同时系统的负载会有一定的提升，系统看似很忙，其实没有处理更多的信息。这种情况可以简单理解为session leak的一种体现。
这个时候我的建议是能够通过一套完善的监控体系来作为oracle工具集的补充，毕竟很多类型的问题，oracle不会都解决完。有些甚至可以自己去写一些脚本之类的来完成。
对session的监控就显得很有意义，我说的session监控，不只是包括active的session，而且包括inactive的session.
比如如下的图表，通过监控工具可以看到在这个下午的时间内，active session都在50个以内，从这些数据来看，判断不出系统到底有没有问题。

如果我们现在假设系统的session数目前最大支持5000~6000，那么就可以设定一个阀值，超过某一个阀值，就是警戒线，就可以说明session存在一定的问题，需要检查，如果再设定一个阀值，超过了这个阀值，就需要立刻做出响应。
对于5000个session的库来说，目前我设定的阀值就是3000~35000，如果session在这个范围内，就需要引起重视，排查到底是什么原因导致的，设定的第二个阀值是4000，如果超过这个范围，问题就很紧急了，需要马上做出响应。尽快的定位问题，及时处理。

回到上面的那个图表，从图表上来说，active session在50个以内，完全不是什么问题。但是我通过一定的脚本得到下面这个列表就会发现这个问题是多么的严重。