日常运维过程中，杀会话是必备技能，最常用的场景->杀锁，处理方式主要两种：

1. 操作系统层面kill进程

2. 数据库层面alter system kill会话

（应用程序强制退出与第二种类似）

想必大家都遇到过数据库层面发起alter system kill session经常出现资源无法及时释放，session一直处于killed状态，如果这个会话是锁的源头，也没啥好的办法只能等着PMON进程清理。而操作系统层面kill进程的方式，基本是百试百灵。

有没有更简便高效的方法呢？对于第一种方式真的只能等着PMON来清理，就没别的方法了？

当然不是，小编给大家介绍两种快速清理状态为killed的会话：

方法一：

找出状态为killed的会话，使用alter system kill 'sid,serial#' immediate命令快速清理，拼接语句如下：

如果是rac的话，添加对应的节点号即可：

方法二：

使用以下命令，查出这些会话对应的系统spid：

日常运维中，以上两种方式是小编常用的两种方法，并且都能快速清理会话。使用系统命令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）杀会话可针对两种场景进行讨论： 

会话状态是active

使用此命令杀active状态会话的时候，过程可以简单概括如下：会话收到kill信号后，会话进行回滚，此过程不可被中断，会话拥有所有资源，直至过程完成，该会话会接收到ORA-00028: your session has been killed信息，PMON清理会话，资源释放。如果1分钟过后，上述动作未完成，则该会话被标记为killed状态，会话拥有资源未释放，等待PMON进程清理会话。

会话是状态inactive

使用此命令杀inactive状态会话的时候，过程简单概括如下：会话收到kill信号后，会话被标记为killed状态，会话拥有资源未释放，等待PMON进程清理会话。如果会话再次发出查询信号，会话会接收到ORA-00028: your session has been killed信息，PMON清理会话，资源释放。

那为何被标记为killed状态的会话，使用以下语句查不到对应会话对应在系统层面真实的spid呢？

这里小编给大家做个小实验：

会话一：

会话二：

会话三：

手动kill 这两个会话：

再次查询这两个会话状态：

从中我们发现，当两个会话状态为killed时，他们会话paddr指向同一地址00000000F26EBDA8（虚拟地址），此地址在操作系统层面无对应的spid，这就是会话被置成KILLED状态之后，使用以下语句查不到spid的原因，如下查询所示。

而此时我们可以使用前文的查询语句，查杀并清理会话

参考文档：

✦ ORACLE (11.2) Database Administrator's Guide (5 Managing Processes)

✦ ORACLE (11.2) Database SQL Language Reference (ALTER SYSTEM)

第一站

温馨提醒

1、在查杀会话时，应考虑直接使用kill或者alter system kill session 'sid,serial#' immediate快速清理会话。

温馨提醒

2、查杀会话时，一定要小心谨慎，千万不要误杀了系统核心进程。

美创运维中心数据库服务团队拥有Oracle ACE 1人、OCM 10余人、数十名Oracle OCP、MySQL OCP、红帽RHCA、中间件weblogic、tuxedo认证、达梦工程师 ，著有《Oracle DBA实战攻略》，《Oracle数据库性能优化方法和最佳实践》，《Oracle内核技术揭秘》等多本数据运维优化书籍。目前运维各类数据库合计2000余套，精通Oracle、MySQL、SQLServer、DB2、PostgreSQL、达梦等主流商业和开源数据库。并成为首批国内达梦战略合作伙伴之一，拥有海量经验和完善的人员培养体系。并同时提供超融合，私有云整体解决方案。