分析一次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都没有注意这一部分，文章中的描述很详细，内容也很好，强烈推荐你们看一看。