Credit: http://www.oracle-base.com/articles/misc/KillingOracleSessions.php
Identify the Session to be Killed
Killing sessions can be very destructive if you kill the wrong session, so be very careful when identifying the session to be killed. If you kill a session belonging to a background process you will cause an instance crash.Identify the offending session using the
V$SESSION
or GV$SESSION
view as follows.TheSET LINESIZE 100 COLUMN spid FORMAT A10 COLUMN username FORMAT A10 COLUMN program FORMAT A45 SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username, s.program FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id WHERE s.type != 'BACKGROUND'; INST_ID SID SERIAL# SPID USERNAME PROGRAM ---------- ---------- ---------- ---------- ---------- --------------------------------------------- 1 30 15 3859 TEST sqlplus@oel5-11gr2.localdomain (TNS V1-V3) 1 23 287 3834 SYS sqlplus@oel5-11gr2.localdomain (TNS V1-V3) 1 40 387 4663 oracle@oel5-11gr2.localdomain (J000) 1 38 125 4665 oracle@oel5-11gr2.localdomain (J001) SQL>
SID
and SERIAL#
values of the relevant session can then be substituted into the commands in the following sections.ALTER SYSTEM KILL SESSION
The basic syntax for killing a session is shown below.In a RAC environment, you optionally specify theSQL> ALTER SYSTEM KILL SESSION 'sid,serial#';
INST_ID
, shown when querying the GV$SESSION
view. This allows you to kill a session on different RAC node.TheSQL> ALTER SYSTEM KILL SESSION 'sid,serial#@inst_id';
KILL SESSION
command doesn't actually kill the session. It merely asks the session to kill itself. In some situations, like waiting for a reply from a remote database or rolling back transactions, the session will not kill itself immediately and will wait for the current operation to complete. In these cases the session will have a status of "marked for kill". It will then be killed as soon as possible.In addition to the syntax described above, you can add the
IMMEDIATE
clause.This does not affect the work performed by the command, but it returns control back to the current session immediately, rather than waiting for confirmation of the kill.SQL> ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;
If the marked session persists for some time you may consider killing the process at the operating system level. Before doing this it's worth checking to see if it is performing a rollback. You can do this by running this script (session_undo.sql). If the
USED_UREC
value is decreasing for the session in question you should leave it to complete the rollback rather than killing the session at the operating system level.
No comments:
Post a Comment