Skip to content
January 25, 2011 / doganay

KILL SNIPED SESSIONS

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Just killing a session is not enough, as the session will remain with the killed status.
As long as you use the sniped status, this means the individual has abandoned his session,
so most probably, he won’t be back to receive the information he was killed and the session
will still be hung with the KILLED status. You have to use a more radical procedure, purge it from the OS:
let’s assume some sessions remain SNIPED: (and of course let’s assume a ux, not windows 🙂 )

SQL> select username, sid, status from v$session where status=’SNIPED’;

USERNAME SID STATUS
———-
HR 132 SNIPED
HR 158 SNIPED

We issue this sqlscritp (killSniped.sql) from the OS

select ‘kill -9 ‘|| spid
from v$process p, v$session s, v$instance i
where p.addr=s.paddr
and s.status=’SNIPED’;

4. You check it from the v$session:

SQL> select username, sid, status from v$session

2 where status=’SNIPED’;

Thx Madrid..

https://forums.oracle.com/forums/profile.jspa?userID=424876

try and pray 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: