Session　Ａ環境：

SQL> conn test/test
Connected.
SQL> select sid,serial#,paddr,status from v$session where sid=userenv('sid');

SID SERIAL# PADDR STATUS
---------- ---------- ---------------- --------
1147 6874 000000021A0D0A70 ACTIVE

Session　Ｂ環境：
SQL> alter system kill session '1147,6874';

System altered.

SQL> select sid,serial#,paddr,status from v$session where sid=1147;

SID SERIAL# PADDR STATUS
---------- ---------- ---------------- --------
1147 6874 000000021A6A9020 KILLED

此時我們查看這個被killed的session只是將session的狀態標記為killed，然后將paddr（session對應的服務器進程的地址）標記為一個虛擬的地址。

過了一段時間，我們還是在Session　Ｂ環境查詢被kill掉的會話，發覺這個會話依然是存在的。
SQL> select sid,serial#,paddr,status from v$session where sid=1147;

SID SERIAL# PADDR STATUS
---------- ---------- ---------------- --------
1147 6874 000000021A6A9020 KILLED

而如果我們重新在原來的session Ａ環境做一些命令查詢，此時會報出session被killeｄ的提示

SQL> select sid,serial#,paddr,status from v$session where sid=userenv('sid');
select sid,serial#,paddr,status from v$session where sid=userenv('sid')
*
ERROR at line 1:
ORA-00028: your session has been killed

再次回到session Ｂ環境查詢這個被killed的會話
SQL> select sid,serial#,paddr,status from v$session where sid=1147;

no rows selected

發現已經沒有任何數據了，此時這個session對應的process也已經被pmon進程釋放了。

記得小魚處理過一個win的庫，有好幾百的session在報出相應的熱點塊現象，通過kill session后，過了很長時間所有的被killed掉session都沒有釋放掉，而這個可能出現的原因數據庫負載太高了，pmon進程并沒有去釋放掉這些session，再就是在ｐｍｏｎ進程釋放之前，需要touch該session才會被pmon進程清除（這個touch的含義是必須有對該session做查詢等請求遞交給server端），一般建議還是通過os級別的kill來釋放session和process。

那么如果我們已經在用kill session的方式killed session，但是進程依然不釋放，此時我們想通過kill spid的方式來釋放session和process。
SQL> select program，spid from v$process where addr in
2 (select p.addr from v$process p where p.pid
1
3 minus
4 select s.paddr from v$session s);

PROGRAM SPID
------------------------------------------------ ------------------------
oracle@dbserver (D000) 26520
oracle@dbserver (S000) 26522
oracle@dbserver (TNS V1-V3) 27932

可以通過上面的查詢先查出兩個視圖中地址不一致的進程，這里需要注意不要kill掉系統的進程，比如這里我們就可以通過上面的查詢手動kill -9 27932來釋放這個session和對應的process。

SQL> !kill -9 27932

SQL> select sid,serial#,paddr,status from v$session where sid=1147;

no rows selected

此時即使我們不touch原來那個session，通過os kill的方式，sesison和process都已經馬上釋放了，個人也建議在維護生產環境中盡量通過os的方式來kill掉需要的session和process。