Re: How do kill a locked session

MarkP28665 wrote in message
<19980117174900.MAA18849_at_ladder01.news.aol.com>...
>From: dtang_at_minn.net >>
>I have seen similiar behavior under Unix system. You have to kill the
 Oracle
>session at the OS level. Under Unix this is a kill -9 pid and under VMS
 this
>is a cancel pid (or whatever VMS calls the job id). I do not know NT, but
 the
>OS should provide a way to terminate a process. Please post what the
 command
>is, when you find it, if NT provides a way to kill a process.

In NT the Oracle background processes run as threads I think. An app can either create a normal thread, or a "remote" thread that runs in the address space of another process.

There's no standard NT command to kill a process, however there are API functions that can be used to terminate processes (with all its threads), or just terminate a single thread. But how are you going to know which is which with Oracle on NT? Does the v$process column spid (server process id) contain the thread or process handle? And is a thread handle always unique within the operating system, or only within a specific process address space?

Even with Unix, I suggest that you only terminate an Oracle process with an o/s command as the last resort. Oracle can behave very strangely when a process just suddenly disappears, especially if it's also using PQ slaves. I had a problem once where some PQ slaves terminated and other PQ slaves continued running after a Unix kill command was used to kill a SQL*Plus process. Rather find the session in v$session and then use the ALTER SYSTEM KILL SESSION command. Oracle will terminate the session and it's associated background/shadow process and perform the necessary cleanup.

BTW, even if the v$session shows a session that you terminated as KILLED, Oracle would still have terminated the corresponding server process. Exactly why sometimes it does this I'm not sure, but I've got a nagging suspicion that Oracle failed to release all the resources and cleanup properly after this killed session. In this case a reboot of the instance will put things right.

My 2'c worth. :-)

regards,
Billy Received on Wed Jan 21 1998 - 00:00:00 CST