--orakill和ALTER SYSTEM KILL SESSION详解【转】
-----------------------------------------2013/11/05
一个用户进程偶尔会挂起或占用过多资源而拒绝其它会话。如果DBA依然能够访问数据库，她通常可以发出以下查询：
select s.username, s.osuser, s.sid, s.serial#, p.spid from v$session s,v$process p
where s.paddr = p.addr and s.username is not null;
select 'alter system kill session ',''''||trim(t2.sid)||','||trim(t2.serial#)||''';'
from v$locked_object t1,v$session t2 where t1.session_id=t2.sid order by t2.logon_time;
这个查询将返回数据库用户名、操作系统用户名、会话 ID，序列号和系统进程 ID（SPID）。然后，DBA 用户就可以发出以下命令（前面的查询返回的使用 SID 和SERIAL# 信息）：
ALTER SYSTEM KILL SESSION 'sid,serial#';
ALTER SYSTEM KILL SESSION '9,203';
使用这条语句有两个问题。
第一：分配给这个进程的任何锁或资源在会话完全超时之前不会被释放。
第二：查询和 kill 命令需要能够访问数据库。如果一个进程失去控制，那么数据库访问可能会出现问题。
在一个 UNIX 数据库中，下一步是 ps 命令输出的 UNIX 提示中定位进程（同样是查找 OSUSER 和 SPID 等 ID）然后使用 kill -9 spid 结束失控的后台进程。然而，在 Windows 中，只有一个进程 ORACLE.EXE，而且用户连接是在 Windows 线程中处理的，而不在进程中处理的。如果使用 Windows 任务管理器结束 Oracle 线程，就有可能影响所有用户和后台线程，并导致数据库崩溃。
出于这些原因，Oracle 在Oracle Home/bin 目录下提供了一个 orakill.exe 命令，这个命令的参数与ALTER SYSTEM KILL SESSION 相同，但是不要求数据库连接。要定位一个特定的线程，需要寻找一个能够显示属于一个进程的所有线程的程序。Windows 任务管理器只能显示线程数和进程。你需要从微软的资源工具包中寻找一个用于 Windows 2000 和 NT 的工具程序，比如免费的QuickSlice，或者Qslice.exe（该工具是基于 Windows 的），或者PStat（Pstat.exe 是一个命令行工具）。简单地在 orakill 命令后输入线程 ID（以十进制表示）和 SID 即可：
orakill <sid> <spid>
orakill ORCL 2760
"Kill of thread id 2760 in instance ORCL successfully signalled[sic]."
应该只有在不能访问数据库来执行ALTER SYSTEM KILL SESSION 的情况才使用orakill。如果意外结束了一个必要的后台进程，比如 PMON，那么很可能会导致数据库崩溃。新手永远不要这样做。
Orakill的使用方法如下：
Dos提示符下:>orakill sid thread
说明： sid Oracle的Sid号
thread Oracle的线程id号
在Sql*plus工具里面可以查询到Oracle的线程号
sql:>Select p.spid THREADID, s.osuser, s.program
From v$process p, v$session s
Where p.addr = s.paddr
结果如下：
THREADID OSUSER PROGRAM
--------- ----------------------- -----------------------------
169 SYSTEM ORACLE.EXE
215 SYSTEM ORACLE.EXE
280 SYSTEM ORACLE.EXE
267 SYSTEM ORACLE.EXE
287 SYSTEM ORACLE.EXE
288 SYSTEM ORACLE.EXE
271 SYSTEM ORACLE.EXE
282 SYSTEM ORACLE.EXE
239 PROD_NTdjones SVRMGRL.EXE
281 SSMITH-PCssmith SQLPLUSW.EXE
12 rows selected.
需要注意的是，如果你Kill掉的是Oracle的核心后台线程(DBWR, LGWR, SMON or PMON),将导致Oracle实例关闭。检查Oracle的核心后台线程的方法如下：
sql:>Select vb.name NOME, vp.programe PROCESSNAME, vp.spid THREADID, vs,sid SID
From v$session vs, v$process vp, v$bgprocess vb
Where vb.addr <> ‘00’ and
vb.paddr = vp.addr and
vp.addr = vs.paddr
查询结果如下：
NOME PROCESSNAME THREADID SID
----- ----------------------------------- --------- ------
PMON ORACLE.EXE 169 1
DBW0 ORACLE.EXE 215 2
LGWR ORACLE.EXE 280 3
CKPT ORACLE.EXE 267 4
SMON ORACLE.EXE 287 5
RECO ORACLE.EXE 288 6
SNP0 ORACLE.EXE 271 7
SNP1 ORACLE.EXE 282 8
8 rows selected.
window xp + oracle 9.2.0.1
================
orakill的用法
================
SQL> SELECT spid, osuser, s.program,sid
FROM v$process p, v$session s
WHERE p.addr=s.paddr;
SPID OSUSER PROGRAM SID
------------------------ -------------------- --------------- ----------
6928 SYSTEM ORACLE.EXE 1
5272 SYSTEM ORACLE.EXE 2
7008 SYSTEM ORACLE.EXE 3
6588 SYSTEM ORACLE.EXE 4
6780 SYSTEM ORACLE.EXE 5
6128 SYSTEM ORACLE.EXE 6
6740 SYSTEM ORACLE.EXE 7
6684 SYSTEM ORACLE.EXE 8
7092 SYSTEM ORACLE.EXE 9
6272 SYSTEM ORACLE.EXE 10
4760 lifeng.fang sqlplus.exe 12
SPID OSUSER PROGRAM SID
------------------------ -------------------- --------------- ----------
6484 lifeng.fang sqlplus.exe 11
4284
语法：orakill 实例名 spid （在win上是线程号）
SQL> host orakill charset 6484;
Kill of thread id 6484 in instance charset successfully signalled.
spid是os进程ID
pid是Oracle process ID
根据盖国强的猜测
当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr 指向同一个虚拟地址.此时v$process和v$session失去关联,进程就此中断.然后Oracle就等待PMON去清除这些Session.所 以通常等待一个被标记为Killed的Session退出需要花费很长的时间.如果此时被Kill的process，重新尝试执行任务，那么马上会收到进 程中断的提示，process退出，此时Oracle会立即启动PMON来清除该session.这被作为一次异常中断处理.
具体的实验例子读者可以参考
http://www.eygle.com/faq/Kill_Session.htm
当然如果该用户已经没有使用，例如在决定删除该用户的时候，PMON很可能不回自动的去清理这些session则需要手工触发PMON执行
首先确认PMON进程是who
SQL> select pid,spid from v$process p,v$bgprocess b
where b.paddr=p.addr
and name='PMON';
PID SPID
---------- ------------
2 3608
SQL> oradebug wakeup 2
已处理的语句
关于oradebug命令可以参考笔者的另一篇文章
http://czmmiao.iteye.com/admin/blogs/1330122