Oracle快速彻底Kill掉等待会话
在Oracle数据库当中,使用ALTER SYSTEM KILL SESSION 'sid,serial#'杀掉一个会话进程。
会话1:
SQL> conn scott/scott
Connected.
SQL>
SQL>
SQL> update emp set empno=5566 where empno=7788;
1 row updated.
SQL>
会话2
SQL> show user
USER is "SYS"
SQL> update scott.emp set empno=3344 where empno=7788;
会话2因为会话1没有提交,造成等待事件。
会话3
SQL> select saddr,sid,serial#,paddr,username,status from v$session where username =upper('scott') or username =upper('sys');
SADDR SID SERIAL# PADDR
---------------- ---------- ---------- ----------------
USERNAME STATUS
------------------------------ --------
000000008E04BD60 1 7 000000008E498608
SCOTT INACTIVE
000000008E7EC578 17 85 000000008E4A8058
SYS ACTIVE
000000008E78A0D0 50 37 000000008E4A4E48
SYS ACTIVE
SQL> set linesize 200
SQL> /
SQL> select saddr,sid,serial#,paddr,username,status from v$session where username =upper('scott') or username =upper('sys');
SADDR SID SERIAL# PADDR USERNAME STATUS
---------------- ---------- ---------- ---------------- ------------------------------ --------
000000008E04BD60 1 15 000000008E498608 SCOTT INACTIVE
000000008E7EC578 17 85 000000008E4A8058 SYS ACTIVE
000000008E78A0D0 50 55 000000008E4A4E48 SYS ACTIVE
SQL> alter system kill session '1,15';
System altered.
kill掉会话1后,会话2的语句就提交了。
SQL> update scott.emp set empno=3344 where empno=5566;
1 row updated.
在会话1执行命令会报如下的错误
SQL> update scott.emp set empno=7777 where empno=5566;
update scott.emp set empno=7777 where empno=5566
*
ERROR at line 1:
ORA-00028: your session has been killed
会话3查询会话状态
select saddr,sid,serial#,paddr,username,status from v$session where username =upper('scott') or username =upper('sys');
SADDR SID SERIAL# PADDR USERNAME STATUS
---------------- ---------- ---------- ---------------- ------------------------------ --------
000000008E7EC578 17 85 000000008E4A8058 SYS ACTIVE
000000008E78A0D0 50 55 000000008E4A4E48 SYS INACTIVE
会话1没有被查询到了。
在其他博客中我遇到过这样的描述:
“有时候会使用ALTER SYSTEM KILL SESSION 'sid,serial#'杀掉一个会话进程,但是使用这个SQL语句杀掉会话后,数据库并不会立即释放掉相关的资源,有时候你会发现锁定的资源很长时间也不会释放,即使会话状态为“KILLED”,依然会阻塞其它会话。 ”
不过我做的实验并没有这种。