Re: Killed sessions

Yup, this is pretty standard behaviour, I think. Killing a session using the SQL command doesn't do anything until the user whose session you've just killed tries to do some new work (say, a select, or a commit).

So as far as PMON is concerned, it's not really dead yet.

Therefore, it's acceptable *after* issuing the SQL command to use operating system commands to physically kill off the process. That pre-empts the issue, and PMON will notice that the session is no longer connected, and do its stuff, without waiting for the user to try something new.

Regards
HJR "murthy" <muthy69_at_yahoo.com> wrote in message news:300217f3.0207080541.26e38cac_at_posting.google.com...
> Hi,
> Hi i had killed several sessions on one of the instances using
> ALTER SYSTEM KILL SESSION ....
> (The instance does not have any Dead connection detection enabled or
> any IDLE TIME set for profile)
>
> The rows for these sessions were still hanging in V$SESSION and i'am
> reaching the PROCESSES limit.
> 1) I tried waking up PMON manually several times using
> svrmgrl>oradebug wakeup 1
> But these rows still remained why?
> 2) Then i did the following
>
> SQL>spool x
>
> SQL>select 'kill -9 '||spid
> from v$process
> where addr not in(
> select paddr
> from v$session
> where status<>'KILLED');
>
> SQL>spool off
> SQL>@x.lst
>
> Now all the KILLED STATUS rows got cleared from V$SESSION.
> My question is is this procedure O.K. ?
> ANy problems is doing this?
> Thanks for any response
Received on Mon Jul 08 2002 - 17:57:02 CDT