今天就跟大家聊聊有关Kill session 和orakill的会话及进程是怎么样的，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
一个用户进程偶尔会挂起或占用过多资源而拒绝其它会话。如果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
已处理的语句
SQL> select p.addr from v$process p where pid <> 1 minus select s.paddr from v$session s; 查询已经KILL的进程地址
ADDR——–
542B70E8
542B7498
看完上述内容，你们对Kill session 和orakill的会话及进程是怎么样的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注亿速云行业资讯频道，感谢大家的支持。
原创文章，作者：kepupublish，如若转载，请注明出处：https://blog.ytso.com/200104.html