今天中午接到同事求助，说是一个应用里面报出了一个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和2000show 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都没有注意这一部分，文章中的描述很详细，内容也很好，强烈推荐大家看一看。
