Clearing OS SPIDs for KILLED sessions

Hi All,
I had killed some sessions in the DB (10.2.0.3) and their status is set to KILLED in v$session.
I am trying to find the OS PIDs of these sessions to do a "kill -9 " but I could not get them. I am using the below query which is not returning anything as the entry does not exist in v$process:
select
p.spid
from v$session s, v$process p
where p.addr = s.paddr
and s.status='KILLED';
Is there any way to get the OS PIDs of these sessions or to clear the KILLED rows from v$session without bouncing the database.
Regards,
Bharath.

hi,
once you kill the user then his process and memory will be released..
post the output of v$session;
regards,
Deepak

Similar Messages

  • Procedure for Killing sessions

    Hi All,
    Almost everyday we have requirement to kill user sessions for dev user, I'm thinking to create a procedure for this and grant to the users so that they can kill it by themself.
    Below is the what I got from Ask Tom forum, however appreciate if someone can share few information if already imlemented in there environment
    <quote>
    create or replace procedure kill_session( p_sid in number,
    p_serial# in number)
    is
    ignore pls_integer;
    BEGIN
    select count(*) into ignore
    from V$session
    where username = USER
    and sid = p_sid
    and serial# = p_serial# ;
    if ( ignore = 1 )
    then
    execute immediate '
    alter system kill session ''' ||
    to_char(p_sid,'999999')||','||
    to_char(p_serial#,'999999')||'''';
    else
    raise_application_error( -20001,
    'You do not own session ''' ||
    p_sid || ',' || p_serial# ||
    end if;
    END;/
    grant execute on kill_session to <username>
    </quote>
    Regards,
    shaan

    rp0428 wrote:
    >
    Instead of killing session with alter systemn kill session, better you opt for below two methods (still perform the same)
    >
    Please clarify what you mean. KILL and DISCONNECT do NOT perform the same.
    From the SQL Language doc
    http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
    KILL is the nice one -
    >
    The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources
    >
    While DISCONNECT is the ogre
    >
    Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever).
    >
    The difference between the two is roughly analogous to the difference between SHUTDOWN IMMEDIATE and SHUTDOWN ABORT.
    I agree that, for OPs use case DISCONNECT (with IMMEDIATE or POST TRANSACTION) may be better since it gets rid of things immediately while KILL can leave things hanging around for a while.From the same link:
    DISCONNECT SESSION Clause:
    The POST_TRANSACTION setting allows ongoing transactions to complete before the session is disconnected. If the session has no ongoing transactions, then this clause has the same effect described for as KILL SESSION.
    The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
    If you also specify POST_TRANSACTION and the session has ongoing transactions, then the IMMEDIATE keyword is ignored.
    If you do not specify POST_TRANSACTION, or you specify POST_TRANSACTION but the session has no ongoing transactions, then this clause has the same effect as described for KILL SESSION IMMEDIATE.
    basically the difference is not between DISCONNECT and KILL SESSION, the difference exists if you allow pending/ongoing transactions to finish(IMMEDIATE vs POST_TRANSACTION)
    Edited by: Keilor on Jun 25, 2012 12:57 PM
    Edited by: Keilor on Jun 25, 2012 1:39 PM

  • Clear the entry for killed/sniped session in v$session

    Dear all,
    In our production database(11.2.0.1.0) running on windows 2008 server many client session showing inactive from last 4-5 hour and I want to kill those session because all sessions are dedicated so for this I created a resource plan set its idle time after certain interval session status is showing killed but it is not removing entries from v$session but our client demand is it must be clear from v$session so for this i was using DOS command taskkill utility to kill particular os process so I want to know what is the smartest way to do this.

    This is known behavior, not an issue.
    In a dedicated server environment when the session is killed and the rollback completes the process goes away so a join between v$session and v$process will fail. The v$session entry also usually goes away rather quickly, though I have seen cases where the v$session entry hung around till the instance was bounced. But normally Oracle will overlay the v$session entry with a new session using the same sid but a different serial# within seconds on a busy system.
    Mark @ http://dbaspot.com/oracle-server/40419-killed-sessions.html
    Metalink doc id 1023442.6 is also something confirming it.
    See also below link and last reply by Mr. Braj Kishore Mahto.
    http://dbaforums.org/oracle/index.php?showtopic=3039
    Regards
    Girish Sharma
    Edited by: Girish Sharma on Nov 21, 2012 5:35 PM
    So, what is best in this regard :
    ALTER SYSTEM DISCONNECT SESSION
    The ALTER SYSTEM DISCONNECT SESSION syntax is an alternative method for killing Oracle sessions. Unlike the KILL SESSION command which asks the session to kill itself, the DISCONNECT SESSION command kills the dedicated server process (or virtual circuit when using Shared Sever), which is equivalent to killing the server process from the operating system. The basic syntax is similar to the KILL SESSION command with the addition of the POST_TRANSACTION clause. The SID and SERIAL# values of the relevant session can be substituted into one of the following statements.
    SQL> ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' POST_TRANSACTION;
    SQL> ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE;
    http://www.oracle-base.com/articles/misc/killing-oracle-sessions.php#disconnect_session

  • Permissions for package owner for kill session?

    What permissions does a package owner need to execute immediate 'alter system kill session' within a package?

    Are you sure? It works for me on 10.2.0.1 (32 bit Windows)
    SYS @ jcave102 Local> drop user bob cascade;
    User dropped.
    Elapsed: 00:00:11.25
    SYS @ jcave102 Local> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    Elapsed: 00:00:00.10
    SYS @ jcave102 Local> create user bob identified by bob default tablespace users;
    User created.
    Elapsed: 00:00:00.07
    SYS @ jcave102 Local> grant create session, create procedure, alter system to bob;
    Grant succeeded.
    Elapsed: 00:00:00.01
    SYS @ jcave102 Local> conn bob/bob
    Connected.
      1  create or replace procedure kill_session( p_sid in number, p_serial# in number )
      2  as
      3  begin
      4    execute immediate 'alter system kill session ''' || p_sid || ',' || p_serial# || '''';
      5* end;
    BOB @ jcave102  > /
    Procedure created.
    Elapsed: 00:00:00.57Now, find a session to kill (using a user other than BOB who doesn't have permission to view the V$SESSION table) and call the procedure
    BOB @ jcave102 Local> exec kill_session( 144, 115 );
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:00.00Justin

  • ALTER SYSTEM KILL SESSION

    Hello Everybody,
    1) Is there any difference between “ALTER SYSTEM KILL SESSION & “kill -9”? Which one is the preferred method?
    2) When we do alter system kill 'sid, serial#'. Are we killing the user process or the server process?
    thanks in advance

    Welcome to the forum!
    Whenever you post provide your 4 digit Oracle version (result of SELECT * FROM V$VERSION)
    >
    Hello Everybody,
    1) Is there any difference between “ALTER SYSTEM KILL SESSION & “kill -9”? Which one is the preferred method?
    2) When we do alter system kill 'sid, serial#'. Are we killing the user process or the server process?
    >
    You should only use the 'kill' from the OS as a last resort.
    There are TWO Oracle options: KILL session and DISCONNECT session. Only rarely, in my experience will DISCONNECT SESSION not get the job done.
    See ALTER SYSTEM in the SQL Language doc
    http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
    >
    end_session_clauses
    The end_session_clauses give you several ways to end the current session.
    DISCONNECT SESSION Clause
    Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever). To use this clause, your instance must have the database open. You must identify the session with both of the following values from the V$SESSION view:
    •For integer1, specify the value of the SID column.
    •For integer2, specify the value of the SERIAL# column.
    If system parameters are appropriately configured, then application failover will take effect.
    •The POST_TRANSACTION setting allows ongoing transactions to complete before the session is disconnected. If the session has no ongoing transactions, then this clause has the same effect described for as KILL SESSION.
    •The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
    ◦If you also specify POST_TRANSACTION and the session has ongoing transactions, then the IMMEDIATE keyword is ignored.
    ◦If you do not specify POST_TRANSACTION, or you specify POST_TRANSACTION but the session has no ongoing transactions, then this clause has the same effect as described for KILL SESSION IMMEDIATE.
    See Also:
    "Disconnecting a Session: Example"
    KILL SESSION Clause
    The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources. To use this clause, your instance must have the database open. Your session and the session to be terminated must be on the same instance unless you specify integer3.You must identify the session with the following values from the V$SESSION view:
    •For integer1, specify the value of the SID column.
    •For integer2, specify the value of the SERIAL# column.
    •For the optional integer3, specify the ID of the instance where the target session to be killed exists. You can find the instance ID by querying the GV$ tables.
    If the session is performing some activity that must be completed, such as waiting for a reply from a remote database or rolling back a transaction, then Oracle Database waits for this activity to complete, marks the session as terminated, and then returns control to you. If the waiting lasts a minute, then Oracle Database marks the session to be terminated and returns control to you with a message that the session is marked to be terminated. The PMON background process then marks the session as terminated when the activity is complete.
    Whether or not the session has an ongoing transaction, Oracle Database does not recover the entire session state until the session user issues a request to the session and receives a message that the session has been terminated.
    See Also:
    "Terminating a Session: Example"
    IMMEDIATE Specify IMMEDIATE to instruct Oracle Database to roll back ongoing transactions, release all session locks, recover the entire session state, and return control to you immediately.

  • Killed sessions

    Hi,
    I kill a session with the commands:
    select username, sid, serial#, status from v$session where username like 'RION%'
    alter system kill session 'sid, serial#'
    and if I give again the first select command at the status column appears KILLED. I want not to have KILLED in the status column.
    Thank you,
    Mihaela

    hi all,
    As u know you are seeing the status of at v$session view as killed, I wanna confirm that this will exists in two senario.
    When a Session is in inactive state and a kill command on that session is issued then the "status" column of v$session will be updated as killed as to indicate/mark as it is killed, and the "server " column will be updated as psuedo. when the user again try to connect to the session user will receive 0ra-00028 error and the entry will be removed from v$session.
    Another senario is that the transaction is at its half way, either in commiting or at the roleback stage for that partucular session then also you can find that the v$table is updated as above.
    more information, go through the documentation, at the Server Process handling section.
    i hope it cleared your confussion,

  • Kill Session in Oracle 10g

    Oracle 10g r2
    I killed a session after fetching the sid and serial from the v$session as under
    select * from v$session where username='SAM';
    alter system kill session '530,7420'
    Now the status showed killed.
    But again after some time one i query the v$session the status turn to inactive.
    Why so?

    Yeah Madrid....
    Thanks for that.. at the developer side.. they did get session killed.
    But actually my doubt here was. that once i killed the session then i go the status as "killed" in the v$session
    but less then a minute when i again query the v$session then i see the status aa inactive. This is what is not clear to me.

  • User lock persists for killed process

    Hi,
    We have an app that acquires a user lock (using dbms_lock, release_on_commit FALSE).
    We needed to kill a session but it remained in v$session (KILLED), even after killing the OS process. Fine, I know it will clear up eventually.
    But the user lock (UL) persists. Does anyone know how it can be force-released?
    Calling dbms_lock.release (using handle in v$lock) fails, even as user SYS, the error being that the user does not own the lock. But the owning session is killed so who can release it?
    Eventually the session (and lock) disappers from v$session/v$lock but can the lock be removed before then, to avoid a DB bounce in an urgent case?
    Thanks

    If the process was truely KILLED and not MARKED FOR KILL then I do not know what could of happened. I cannot remember Oracle ever failing to release a user lock when the acquiring session was terminated. We use a fair number of UL; however, few of our processes have concurrent sessions that attempt to use the same UL. Mostly we just ensure that batch processes do not get submitted twice and that some on demand processes run single threaded or do not run if another customer has submitted the task.
    HTH -- Mark D Powell --

  • Alter system kill session in RAC

    Hi,
    After identifying all inactive jdbc sessions or blocking sessions from gv$session or gv$lock respectively, should alter system kill session executed in both instances of RAC?, Can't we execute like alter system kill session ' inst_id,sid,serial#' from a single instance to kill all the session of RAC instances?
    So, above problem answered in 11g as:
    Alter system kill session ‘SID, serial#, @instance_id’;
    Eg: ALTER SYSTEM KILL SESSION ‘115,9779,@1';
    So, In our environment, most of the databases are in 10gR1 or 10g R2. Is there any patch for 10g Where instance_id can be recognized by alter system kill session?
    Thanks,
    Sunil.

    Hi Dan,
    Not sure what you mean by "instance specific kill session capability".
    To be clear, I'm speaking of a new feature, introduced in 11gR1, that provides for an optional third parameter to 'alter system kill session', which allows you to kill a session on a remote instance, in a RAC environment.
    Documentation is here:
    http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_2013.htm#i2065117
    -Mark

  • Killed session still showing in V$session

    I have killed some 5 sessions. Its status is reflecting as KILLED for last 10 days. I searched for the relevant OS process to completely scratch the session. But it returned none.
    Now i have that KILLED session in V$session view and no process from OS level.
    How can i remove that KILLED entry from v$session view?

    Those status KILLED in your V$SESSION you will have to kill them by the Operation System (kill -9 "spid"). So, you'll have to find in the V$PROCESS the SPID (process number) from the 5 killed session that you have. In a normal situation, with statuses ACTIVE or INACTIVE, you can easily find the SPID with:
    "select p.spid, s.username, s.status from v$process p, v$session s where s.paddr=p.addr".
    But, sometimes, when you have "KILLED" sessions for a long time, this link between both dict views are lost and you have to find all the SPID that doesn not have child record on v$session.
    You have to do this carefully, because you cannot kill (on OS) the Oracle Processes (pmon, dbwr, etc..).
    Paulo.

  • Killing sessions

    hi,
    i am using oracle 11gr1 in windows server service pack2.i have generated scripts to kill the user using alter system kill session 'sid,serial# and then dropping the same user.But at times i get the error that cannot drop user who is currently connected .when i check the state of the user in v$session it is in killed state.i want to avoid this and kill the user perfectly.
    can anyone tell me the solution or suggestion for this????
    thanks in advance
    Edited by: 793097 on Dec 17, 2010 3:12 AM

    A remote session open a server session, this is the one you must kill.
    I'm not sure, but when you kill a session the relation between v$process and v$session disapear. Then all you can do is wait.
    Perhaps I am wrong. Try this,
    select 'kill -9 ' || b.spid from v$process where b.addr = <v$session killed paddr>;
    And run the kill in OS, if OS is linux or unix...
    I am very sorry that we never help to you...
    793097 Newbie
    Handle:      793097
    Status Level:      Newbie (15)
    Registered:      Sep 6, 2010
    Total Posts:      94
    Total Questions:      57 (49 unresolved)
    Read this http://forums.oracle.com/forums/ann.jspa?annID=718

  • Kill session not killing.

    I have searched the forum and could not find anyone with this problem.
    I have many sql tools to get the serial# and session data to kill sessions that have been connected for more than 3-7 days.
    I alter system kill session 'sid, serial';
    result: system altered.
    But when I query again the same "killed" session is still showing. Has anyone had this issue before? Is there such a thing as "zombie" sessions that hit Oracle. Most of theses sessions I am trying to kill are more than 2 weeks old and I assume idle.
    We are running 10g (10.1.0.2.0) on Linux AS3.

    Hi,
    54 ?? Then you you can kill these processes on OS level: kill <spid>
    Be sure you do not kill background processes such as below:
    SYSTEM@ORACLE10> select c.name, b.spid, a.sid
      2  from v$session a, v$process b, v$bgprocess c
      3  where c.paddr  <> '00'
      4  and c.paddr =  b.addr
      5  and b.addr  =  a.paddr;
    NAME  SPID                SID
    PMON  3313                280
    MMAN  3315                279
    DBW0  3317                278
    LGWR  3319                277
    CKPT  3321                276
    SMON  3323                275
    RECO  3325                274
    CJQ0  3327                273
    QMNC  3333                269
    MMON  3335                268
    MMNL  3337                266Cheers

  • Killing session

    Dear all,
    If we kill session at OS LEVEL by using the command "KILL -9 <SPID>"
    or
    At the database level if we kill the session by issuing the command <alter system kill session 'sid,serial#' immediate>
    If any dml transaction is going on suppose "UPDATE" statement , in the middle of the transaction if we kill the transaction at OS LEVEL or at the DATABASE LEVEL , that particular transaction will rollback or it won't.
    Please help me regarding this.
    Regards,
    Vamsi.

    844795 wrote:
    Dear all,
    If we kill session at OS LEVEL by using the command "KILL -9 <SPID>"
    or
    At the database level if we kill the session by issuing the command <alter system kill session 'sid,serial#' immediate>
    If any dml transaction is going on suppose "UPDATE" statement , in the middle of the transaction if we kill the transaction at OS LEVEL or at the DATABASE LEVEL , that particular transaction will rollback or it won't.
    Please help me regarding this.Why you didn't search for this in the Oracle documentation?
    http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/manproc008.htm#ADMIN11192
    Aman....

  • How to clear the variable value in session store?

    I'll try to build form for search. There are LOV and
    search button on form. When user don't select anything then push
    search button, I'd like the report to show query everything. I
    mean the report will show like condition where id like '%'.
    And I send variable between form to report by using session
    store.
    I select nothing in LOV but value that return by LOV is
    not null. It's in stead of old value of LOV.
    Please tell me.. How to clear the variable value in
    session store? I'd like to set it to null. If you have greater
    way to do like this, please tell me.
    Thank you.

    Please suggest on this..
    Thanks.

  • How to kill session in forms

    In my application I want to kill session if any user
    is idle for 2 minutes.
    I am using oracle forms 6i and database oracle 9i

    You have to use D2KWutil.pll
    In when new form instance write the following code
    declare
    hWind PLS_INTEGER;
    CheckTimer TIMER;
    begin
    hWind := get_window_property(FORMS_MDI_WINDOW,WINDOW_HANDLE);
    Win_API_Session.Timeout_Start_Timer(hWind);
    CheckTimer := Create_Timer('CheckTimeout',1000,repeat);
    end;
    and in when timer expired trigger write the following code
    begin
    if upper(get_application_property(TIMER_NAME)) = 'CHECKTIMEOUT' then
                   :timer.t1 := Win_api_session.Timeout_Get_Inactive_Time;     
    if :timer.t1 > 120 then -- timer is a block and t1 is text item (don't assign a canvas to it, make it invisible)
    Win_API_Session.timeout_delete_timer;
    exit_form (NO_VALIDATE);
    end if;
    end if;
    end;
    hope this helps !!

Maybe you are looking for