最近有个测试库刚出现的情况，
现象：
以前一直未出现过这种状态：
有的应用(这里部署的应用有100多个，且都是Tuxedo长连接数据库 的应用)每天第一次执行时报：ORA-02396: exceeded maximum idle time, please connect again
过段时间会有应用报错：ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit，此时也无法登录数据库了。

测试库信息：
版本：9.2.0.7.0

判断问题思路：
SELECT * FROM v$session WHERE username='STAR' ORDER BY status;
查看有许多都是SPINED状态的。

用下面的语句产生的kill -9 ...会提示no such process或invalid id，SPID不是OS进程的ID么？

SELECT s.username,s.status,s.machine,osuser,spid,
 'kill -9 '||spid UNIX_level_kill,
 'alter system kill session ' ||''''||s.sid||','||s.serial# || ''';' Oracle_level_kill,
 TO_CHAR (logon_time, 'dd/mm/yyyy hh24:mi:ss') logon_time,
 last_call_et idle_time,
 TO_CHAR (TRUNC (last_call_et / 3600, 0))||' '||' HRS '||TO_CHAR (TRUNC ((last_call_et - TRUNC(last_call_et / 3600, 0) * 3600) / 60, 0)) ||' MINS' idle_time_hour_minute,
 module 
 FROM v$session s, v$process p
 WHERE TYPE = 'USER'
 AND s.username='STAR'
 AND p.addr = s.paddr
 AND status = 'SNIPED' 
 -- AND SUBSTR (machine, 1, 19) NOT IN ('machine')
 AND last_call_et > 60 * 60 * 2
 -- session idle time more than 1 hour
 
ORDER BY last_call_et desc;


问题的原因：

就是由于设置了资源计划这种profile，idle_time是60分钟，sessions_per_user是60。


解决方法：

最直接的就是将该用户的profile改为DEFAULT，若不修改默认，则DEFAULT的idle_time和sessions_per_user都是unlimited。


再解释下v$session中：

SPINED状态的session问题，根据@dbsnake大拿的意思，这种状态是Oralce自身判断需要kill -9干掉OS进城后的状态，但该session还在v$session，这时只能用alter system干掉该session。至于上述"SPID不是OS进程的ID么"的问题，则是因为Oracle内部已经用kill -9干掉该进程了，那当然提示no such process等错误。

KILL状态的session，是使用alter system从Oracle级干掉的session，等待事务回滚。

INACTIVE状态表示当前的这个session处于非活动状态，比如打开一个PLSQL但没有操作。

ACTIVE表示正处于active，例如当前在一个PLSQL的SQL Window。


说明：

处于SNIPED的session，例如用PLSQL登陆的超时了，被kill -9，此时不要重新登录，只需要执行一条SQL，它会报错，此时从另一个session看该SNIPED的session被清空了，否则需要用alter system删除该session。