Life after ALTER SYSTEM KILL SESSION

What can stop ALTER SYSTEM KILL SESSION 'n,n' from actually killing a session?
A particular example: A multi-threaded application runs on a separate server against an Oracle 8.1.7 database. The server running the application restarts. When running a query for the current database sessions using v_$session the now dead application's sessions still appear. Issuing a KILL seems to make no difference.

The sessions eventually disappear from v_$session but I am unsure as to whether the DB has tidied these up because it realises they are inactive or because the KILL has marked them as inactive and the DB gets around to tidying them up. In any case why would the database not kill the session immediately as it does other user sessions? Or, is the database killing the sessions immediately and v_$session just isn't the right place to look?

I would appreciate any help.
LVL 2
IanBlundellAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

schwertnerCommented:
Old problem! Nobody knows when the session will be  killed! An old posting here claims that sometimes this can take days.
0
seazodiacCommented:
I found this very true too.

Alter system kill session works mostly for sessions from sqlplus but not for external application such as JDBC, ODBC apps.

And I checked this with Oracle metalink, here is what they told me:
It is true that alter system kill session does not actually kill them.
What is always said is server need to rollback all uncommited changes and as it is done by PMON in backgraund it is much slowlier than done by user process itself when explicit rollback statement issued.

If an active session cannot be interrupted (for example, it is performing network I/O or rolling back a transaction), the session cannot be terminated until the operation completes. In this case, the session holds all resources until it is terminated. Additionally, the session that issues the ALTER SYSTEM statement to terminate a session waits up to 60 seconds for the session to be terminated; if the operation that cannot be interrupted continues past one minute, the issuer of the ALTER SYSTEM statement receives a message indicating that the session has been "marked" to be terminated. A session
marked to be terminated is indicated in V$SESSION with a status of "KILLED" and a server that is something other than "PSEUDO."

If the transaction cannot be rolled back by pmon, you may find errors or something indicating what the problem was in the pmon background trace file.


Hope this helps

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AlbertYouCommented:

Hi all,

I have recorded a solution in a PAQ.
You can try to killing the operating system process or thread:

1. Killing sessions in WINDOWS 2000/NT
issue in a DOS command window:
orakill sid thread

where sid    = the Oracle instance to target
        thread = the thread id of the thread to kill
   The thread id should be retrieved from the spid column of a query such as:
         select spid, osuser, s.program from
        v$process p, v$session s where p.addr=s.paddr
 You can find ORAKILL.exe in $ORACLE_HOME\bin

2. Killing sessions in UNIX:

select vs.sid, vs.username, vs.osuser, vs.process fg_pid, vp.spid bg_pid
from v$session vs, v$process vp
where vs.paddr = vp.addr

SID  USERNAME        OSUSER     FG_PID    BG_PID
---- --------------- ---------- --------- ---------
14   QZBHS1          QZBHS1     2924:3744 1948
29   QZBHS1          QZBHS1     3632:3844 15452
51   QZBHS1          QZBHS1     4644:3892 5438

Issued in unix (as the oracle unix user, the user thats owns the database) :

kill -9 1948
kill -9 15452
kill -9 5438


Hope this can help you.

Albert.
0
IanBlundellAuthor Commented:
Experts

Thanks for your responses. In an attempt to be fair handed I am going to spread out the points as follows:

schwertner: 40 points for the most concise answer.
seazodiac: 50 points for an expanded answer with some pointers.
AlbertYou: 35 points for a way to try and kill the errant sessions (although this wasn't requested - it might come in useful).

0
jim_1234567890Commented:
I have found that the orakill does not always work in windows enviroment.

Sometime the user restart their computer in hopes that it will remove the 'Killed' status.

So when I for example issue:
orakill 28 3124

I get an error saying:
Could not attach to Oracle instance 28: err = 2

And the process still sticks around.



0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.