今天開發反饋說，執行某個程序update的時候hang住，查看了一下是個小表，只有3000多行數據。第一反應是有鎖，把該實例的所有session kill後，執行update還是hang住，單獨執行了下where條件後面的select很快。於是覺得應該是在2節點上還有lock，於是執行查詢：
select * from gv$lock where id1=383105;
SQL> select * from gv$lock where id1=383105;
INST_ID ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
2 0000000110AF61B0 0000000110AF6210 1333 TM 383105 0 3 0 6819 2
果然，2節點上還有一個session持有鎖。
連接到2節點，執行查詢：
SQL> select sid,serial#,osuser from v$session where sid=1333;
SID SERIAL# OSUSER
1333 22559 6005821 alter system kill session '1333,22559';
殺了會話後，再查詢，發現1333的session還存在：
SQL> select sid,serial#,osuser from v$session where sid=1333;
SID SERIAL# OSUSER
1333 22559 6005821 於是想從系統層kill，可是通過以下sql查詢不到1333的spid
select p.pid,p.spid,s.sid,s.serial# from v$process p,v$session s where s.paddr=p.addr and s.sid=1333;
查詢後發現，當在Oracle中kill session以後, Oracle只是簡單的把相關session的paddr 指向同一個虛擬地址.此時v$process和v$session失去關聯,進程就此中斷。 然後Oracle就等待PMON去清除這些Session.所以通常等待一個被標記爲Killed的Session退出需要花費很長的時間. 如果此時被Kill的process，重新嘗試執行任務，那麼馬上會收到進程中斷的提示，process退出，此時Oracle會立即啓動PMON 來清除該session.這被作爲一次異常中斷處理.
根據以下sql找到之前的paddr：
select p.addr from v$process p where pid <> 1
minus
select s.paddr from v$session s;
07000107C8C050F8
07000107DCC19D88
根據v$process的addr找到spid：
select * from v$process where addr in ('07000107C8C050F8','07000107DCC19D88');
然後找到系統進程號，殺掉就好了。由於部分過程沒有保留下執行結果，就只有記錄下sql了。
oracle@cq2:] ps -ef|grep 8847870
oracle 8847870 1 3 Aug 06 - 734:23 ora_pz99_CQRPT2
oracle 10420652 13107576 0 11:11:01 pts/1 0:00 grep 8847870
[oracle@cq2:] ps -ef|grep 14221746
oracle 12583324 13107576 0 11:11:22 pts/1 0:00 grep 14221746
oracle 14221746 1 0 08:16:07 - 0:04 oracleCQRPT2 (LOCAL=NO)
[oracle@cq2:] kill -9 14221746
[oracle@cq2:] ps -ef|grep 14221746
oracle 12583046 13107576 0 11:12:11 pts/1 0:00 grep 14221746
測試過程還可以查看另一文章：https://www.cnblogs.com/kerrycode/p/4034231.html