日常运维过程中，杀会话是必备技能，最常用的场景->杀锁，处理方式主要两种：
1）操作系统层面kill进程
2）数据库层面alter system kill会话
（应用程序强制退出与第二种类似）
想必大家都遇到过数据库层面发起alter system kill session经常出现资源无法及时释放，session一直处于killed状态，如果这个会话是锁的源头，也没啥好的办法只能等着PMON进程清理。而操作系统层面kill进程的方式，基本是百试百灵。
有没有更简便高效的方法呢？对于第一种方式真的只能等着PMON来清理，就没别的方法了？
当然不是，下面给大家介绍两种快速清理状态为killed的会话：
方法一：
找出状态为killed的会话，使用alter system kill ‘sid,serial#’ immediate命令快速清理，命令如下：
alter system kill session 'sid,.serial#' immediate;
拼接语句如下：
select 'alter system kill session '''||sid||','||serial#||''' immediate;' from v$session c where status='KILLED';
如果是rac的话，添加对应的节点号即可：
select 'alter system kill session '''||sid||','||serial#||',@'||c.inst_id||''' immediate;' from v$session c where status='KILLED';
方法二：
使用以下命令，查出这些会话对应的系统spid：
select username, spid, program, 'kill -9 ' || spid
from v$process a
where a.addr in (select p.addr from v$process p where pid <> 1 minus select s.paddr from v$session s)
and a.PNAME is null;
日常运维中，以上两种方式都能快速清理会话。使用系统命令kill -9 杀死进程，系统向该process进程发出sigkill，sigkill信号直接发送给init进程，终止process进程。这种方式直接终止了ORACLE session对应的process进程，资源可直接释放。
这里给大家详解下alter system kill session 过程，以及为何alter system kill session杀了会话之后，查不到killed状态会话对应的系统进程spid。
alter system kill session（不加immediate）杀会话可针对两种场景进行讨论：
1、会话状态是active
使用此命令杀active状态会话的时候，过程可以简单概括如下：
会话收到kill信号后，会话进行回滚，此过程不可被中断，会话拥有所有资源，直至过程完成，该会话会接收到ORA-00028: your session has been killed信息，PMON清理会话，资源释放。
如果1分钟过后，上述动作未完成，则该会话被标记为killed状态，会话拥有资源未释放，等待PMON进程清理会话。
1、会话状态是inactive
使用此命令杀inactive状态会话的时候，过程简单概括如下：
会话收到kill信号后，会话被标记为killed状态，会话拥有资源未释放，等待PMON进程清理会话。
如果会话再次发出查询信号，会话会接收到ORA-00028: your session has been killed信息，PMON清理会话，资源释放。
那为何被标记为killed状态的会话，使用以下语句查不到对应会话对应在系统层面真实的spid呢？
select b.sid, b.serial#, c.spid, b.status
from v$session b, v$process c
where b.paddr = c.paddr
and b.sid = &sid;
这里给大家做个小实验：
会话一：
会话二：
会话三：
手动kill 这两个会话：
再次查询这两个会话状态：
从中我们发现，当两个会话状态为killed时，他们会话paddr指向同一地址00000000F26EBDA8（虚拟地址），此地址在操作系统层面无对应的spid，这就是会话被置成KILLED状态之后，使用以下语句查不到spid的原因，如下查询所示。
而此时我们可以使用前文的查询语句，查杀并清理会话:
原文：公众号【新运维新数据】运维日记|你真的会查杀会话了吗？