【Oracle】-【v$session】v$session的SNIPED状态


【Oracle】-【v$session】v$session的SNIPED状态
 
最近有个测试库刚出现的情况，
现象：
以前一直未出现过这种状态：
有的应用(这里部署的应用有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。