分析一次ORACLE数据库Session暴增的问题

前端之家收集整理的这篇文章主要介绍了分析一次ORACLE数据库Session暴增的问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

今天中午接到同事求助,说是一个应用里面报出了一个ORACLE错误,于是帮助他看了看,虽然最终没有解决他的问题(问题不是出在ORACLE数据库层面),还是把分析步骤发出来分享一下。

问题情况:
一个应用程序执行失败了,在问题日志中,发现如下报错。

问题分析:
这个报错很明显,是ORA-12519错误,具体的意思就是TNS:no appropriate service handler found(没有合适的服务处理器) ,我们可以上网去查一查这个错误号,基本的矛头都指向了数据库的Session和Process被占满。

问题细化分析:

  • 执行命令
    select count(*) from v$process ;
    select value from v$parameter where name = 'processes' ;
    得到答案是::1965和2000
    show parameter session;
    select count(*) from v$session;
    得到答案是:3072和1961
    乍一看,session数还没有吃满,但是process已经要到峰值了,这个就可能引起ORA-12519。
    并且session虽然没有吃满,但是也挺高,所以我接下来的分析偏向Session数部分,后面我会再放一篇文章,来说下其他情况。
  • 分析V$session表
    其实我一开始分析到这里,我给的建议是要么先停库放掉Session和process,挨个应用启动看看,要么找后台看程序的问题,但是实际业务不允许停库,找后台看又过于耗时,所以再打算继续细化分析一下。
    我首先让他查一下数据库当前的锁表情况,看看是不是因为某些表锁了引起session一直增长,查询后发现没有锁表,也就排除了这个可能。
    之后,导出V$session这张表,来进行分析,我们筛选一下导出后的结果,这张表总数就是1961个,但是其中一个localhost.localdomain这台机器,有1061个session在sys$user下执行,这明显不正常。
  • 后续的内容,需要现场配合完成
    到这里我给出的建议是,需要现场结合应用实际情况,来针对这些异常Session进行分析,找出是哪些应用程序在耗费Session,DBA层面可能只能帮助现场分析到这一步(虽然自己现在还不是,哈哈),后续的内容还得现场来完成。
  • 引申思考,自己有没有分析的不对的地方?
    我又仔细的缕了一遍问题现象,发现自己貌似没有关注V$process这张表,于是我又查了一些内容,发现一个问题,那就是:密码过期会导致Oracle process耗尽

这里我放一个链接http://blog.csdn.net/leftfist...

这篇文章说的情况,大概是这样的,即Process吃满,但是Session数特别小,这样就排除了数据库本身的操作引起process数的暴涨,跟今天分析的内容不太一样,但是特别具有预警意义,可能很多11g的oracle都没有注意这一部分,文章中的描述很详细,内容也很好,强烈推荐大家看一看。

猜你在找的Oracle相关文章