[Oracle]-[v $ session] v $ session's SNIPED status

[Oracle]-[v $ session] The SNIPED status of v $ session has just appeared in a test database recently. symptom: This status has never existed before: some applications (here deployed more than 100 applications, and are Tuxedo Persistent Database Connection applications) the first execution every day: ORA-02396: exceeded maximum idle time, please connect again an application error occurs over a period of time: ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit, and you cannot log on to the database at this time. Test Database Information: Version: 9.2.0.7.0 train of thought: SELECT * FROM v $ session WHERE username = 'star' order by status; Check that many of them are in the spin state. The kill-9 generated by the following statement will prompt no such process or invalid. Isn't SPID the OS process 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_ti Me_hour_minute, module FROM v $ session s, v $ process pWHERE TYPE = 'USER' AND s. username = 'star' AND p. addr = s. paddrAND status = 'sniped' -- and substr (machine, 1, 19) not in ('machine ') AND last_call_et> 60*60*2 -- session idle time more than 1 hourORDER BY last_call_et desc; cause: the profile of resource planning is set, AND idle_time is 60 minutes, sessions_per_user is 60. Solution: change the profile of the user to DEFAULT. If the DEFAULT value is not modified, the DEFAULT idle_time and sessions_per_user are all unlimited. Next, let's explain the question of the session in the spin state in v $ session. According to @ dbsnake danale, this state is the state in which Oralce determines whether to kill the OS after it enters the city, however, the session is still in the v $ session. In this case, you can only use alter system to kill the session. As for the above "SPID is not the OS process ID" problem, it is because Oracle has used kill-9 to kill the process, it certainly prompts no such process and other errors. Sessions in the KILL state are sessions that are killed from Oracle using alter system, waiting for transaction rollback. INACTIVE indicates that the current session is INACTIVE. For example, if a PLSQL statement is opened but no operation is performed. ACTIVE indicates that the SQL Window is active, for example, in a PLSQL statement. Note: The session is in SNIPED State. For example, if PLSQL login times out and is killed-9, do not log on again. You only need to execute an SQL statement, which will report an error, in this case, we can see from another session that the SNIPED session has been cleared. Otherwise, we need to use alter system to delete the session.