你好,游客 登录 注册 搜索
背景:
阅读新闻

关于ORA-00020问题的反思

[日期:2014-09-23] 来源:Linux社区  作者:jeanron100 [字体: ]

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

更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址http://www.linuxidc.com/Linux/2014-09/107096.htm

linux
相关资讯       ORA-00020 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款