今天在生产环境中查看alert日志，发现了如下的一段错误。这个错误确实没有太多需要解释的。很明显就是因为ses本文来源gaodai#ma#com搞*!代#%^码网%sion leak的经典问题
今天在生产环境中查看alert日志，发现了如下的一段错误。这个错误确实没有太多需要解释的。很明显就是因为session leak的经典问题。
ORA-00020: maximum number of processes 5000 exceeded
ORA-20 errors will not be written to the alert log for
the next minute. Please look at trace files to see all
the ORA-20 errors.
Fri Sep 19 12:39:38 2014
Process W001 submission faile
这个问题的分析思路就是查看对应的awr报告。可以得到一些信息。
如果能够定位到一些明显的问题，那就很顺利了，如果不行，还得缩小时间范围。看看ash报告找到更多的信息。
Snap Id Snap Time Sessions Curs/Sess
——— ——————- ——– ———
Begin Snap: 14866 19-Sep-14 12:00:13 3,926 3.6
End Snap: 14867 19-Sep-14 13:00:17 2,693 6.7
Elapsed: 60.07 (mins)
DB Time: 4,202.97 (mins)
ash报告虽然可以提供很多有效的问题处理思路，，但是对于session的监控却无能为力。
而且ASH中得到的是active session的一些信息，比如应用存在问题，连接没有及时释放，这些session都是在inactive状态，在ash报告中也不会体现。
awr报告中如果两个快照的时间够短，可能得到的session的信息就比较详细了，但是session的信息是实时变化的，快照的间隔太短也不现实。
这个时候个人建议就是自己写一写脚本来监控session的情况。尽管很多的历史信息都可以在Oracle中查到，但是根据需要oracle满足不了我们很多的需求。
提供一些分子的档案库也是对oracle的补充，而且出了问题之后能够更加快捷有效的排查问题。
比如说上面这个ora错误，一般从大体的角度都会问几个问题。
一般生产环境的session情况是怎么样的。
这个问题出现的频率，从什么时候开始出现的。
怎么预防。
如果没有一些数据支持，是最怕领导这么问的。但是一旦你有了自己的档案库，不完全依赖于数据库，就会有得到很多的额外收获。
这个时候一个简单清晰的图标就可以让领导一目了然。
以上是一个简单的截图部分，数据的情况就一目了然了。有几天的session数特别低，那是因为做了升级工作。之后session数开始抖动。就能够比较及时的发现问题。
至于说怎么预防，还得和开发部门协调，但是从dba的角度来说我们能够提供足够的信息和支持。
本文永久更新链接地址：
转载请注明原文链接：关于ORA-00020问题的反思
