--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