关于ORA-00020问题的反思(r2笔记第3天）

今天在生产环境中查看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的角度来说我们能够提供足够的信息和支持。