在生产环境中，作为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个以内，完全不是什么问题。但是我通过一定的脚本得到下面这个列表就会发现这个问题是多么的严重。
一共5000的session，现在达到了4900多，已经没有多少富余的session了。需要马上定位问题。
首先是需要定位session占用过多的program部分是哪些。通过如下的排查马上可以发现jdbc客户端中占用了过多的session。
.......
定位了program的部分，就开始定位machine,username。更多的监控信息可以参考
通过shell脚本监控oracle session
http://blog.itpub.net/23718752/viewspace-776143/
马上能够定位到session是从某台服务器上连过来的，这个时候就需要马上定位这台服务器上运行 的程序。
可以通过随机抓取一部分session的信息，然后通过sid来查看目前inactive 状态的session之前运行的sql语句来排查。
select sql_id prev_sql_id ,sql_text from v\$sql where sql_id in (select prev_sql_id sql_id from v$session where (sid||','||serial#)='$1' ) and rownum
通过这些步骤肯定能够得到一些有用的信息。
今天的这个案例中，我发现很多inactive的session都是连续的，我就随机抓取了2个session，然后从查看执行过的sql记录，发现都是同一个insert语句。这样可以提供这些信息给相应的开发和系统部分来马上处理。
经过排查，他们发现确实是一个session leak的问题，经过讨论，启用了2个job在处理，占用了过多的资源，但是这两个job的优先级不是很高，所以可以稍后处理，就这样把这两个job先停掉，session的占用率马上就降下来了。
通过这个问题的排查是想说明不要完全依赖某个工具，要有自己的思路来处理问题，设定session的管理阀值就是一个衡量系统健康的指标。
比如说对于生产环境的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个以内，完全不是什么问题。但是我通过一定的脚本得到下面这个列表就会发现这个问题是多么的严重。
STATUS CNT
-------- ----------
ACTIVE 58
INACTIVE 4889
----------
sum 4947
一共5000的session，现在达到了4900多，已经没有多少富余的session了。需要马上定位问题。
首先是需要定位session占用过多的program部分是哪些。通过如下的排查马上可以发现jdbc客户端中占用了过多的session。
PROGRAM CNT STATUS
----------------------------------- ---------- --------
JDBC Thin Client 4338 INACTIVE
extract@xxxxxxx(TNS V1-V3) 60 INACTIVE
java_q4p@xxxxxxxx(TNS V1-V3) 40 INACTIVE
java@xxxxxxxx(TNS V1-V3) 31 INACTIVE
java_q4p@xxxxxxxx(TNS V1-V3) 31 INACTIVE.......
定位了program的部分，就开始定位machine,username。更多的监控信息可以参考
通过shell脚本监控oracle session
http://blog.itpub.net/23718752/viewspace-776143/
马上能够定位到session是从某台服务器上连过来的，这个时候就需要马上定位这台服务器上运行 的程序。
可以通过随机抓取一部分session的信息，然后通过sid来查看目前inactive 状态的session之前运行的sql语句来排查。
select sql_id prev_sql_id ,sql_text from v\$sql where sql_id in (select prev_sql_id sql_id from v$session where (sid||','||serial#)='$1' ) and rownum
通过这些步骤肯定能够得到一些有用的信息。
今天的这个案例中，我发现很多inactive的session都是连续的，我就随机抓取了2个session，然后从查看执行过的sql记录，发现都是同一个insert语句。这样可以提供这些信息给相应的开发和系统部分来马上处理。
经过排查，他们发现确实是一个session leak的问题，经过讨论，启用了2个job在处理，占用了过多的资源，但是这两个job的优先级不是很高，所以可以稍后处理，就这样把这两个job先停掉，session的占用率马上就降下来了。
通过这个问题的排查是想说明不要完全依赖某个工具，要有自己的思路来处理问题，设定session的管理阀值就是一个衡量系统健康的指标。
