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

问题情况：

问题分析：

问题细化分析：

• 执行命令
  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耗尽

这里我放一个链接：

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