关于ORA-00020问题的反思

关于ORA-00020问题的反思

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