在上周巡检系统的时候发现session列表中显示有一个session的状态为“KILLED",当时没有太在意，等到周一回来做检查的时候，发现那个session的状态还是为KILLED.
这肯定是个问题，我们来看看这个session的情况。从v$session里可以看出这个session最早是在7月8日初始化的。

SQL>  select sid,serial#,status,logon_time ,paddr from v$session where status='KILLED';
       SID    SERIAL# STATUS           LOGON_TIME          PADDR
---------- ---------- ---------------- ------------------- ----------------
       979      64731 KILLED           2015-07-08 17:51:23 000000174114A1D8
查看一些客户端的明细信息，可以看到，是通过sqlplus直接连过来的，从客户端信息来看是一个监控客户端。
USERNAME             PROGRAM                                            OSUSER               MACHINE              STATUS                  SID
-------------------- -------------------------------------------------- -------------------- -------------------- ---------------- ----------
MIN_BG      sqlplus@xxxxxx (TNS V1-V3)                     xxxxx                   xxxxxxxxxx           KILLED                  979
这个时候尝试去看看这个session在killed的时候正在执行什么sql语句。没有任何信息。       
select sql_id from v$session where paddr='000000174114A1D8' and sql_id is not null 

好了问题的情况就是这样，之前也分享过几篇关于kill session的博文，比如http://blog.itpub.net/23718752/viewspace-1485804/
那个问题是通过查看操作系统进程来查看对应的session信息。
这个问题不太一样，因为我们只知道session的信息，需要找到绑定的操作系统进程。
有一个思路可以参考，我们根据操作系统进程的初始化时间来查看7月8日的数据相关进程。发现只有2个。这对我们分析问题的范围来说就更小了。
$ ps -ef|grep Jul08
oracle     781     1  0 Jul08 ?        00:00:00 oracletlbb3dbi (LOCAL=NO)
oracle   12172 10679  0 10:29 pts/0    00:00:00 grep Jul08
oracle   36470     1  0 Jul08 ?        00:00:00 oracletlbb3dbi (LOCAL=NO)
所以这两个进程中应该有一个就是需要清理的进程。
我们看看781这个进程。可以看到v$session里的paddr和v$process里的addr还是完全对应的，证明这个session是没有问题的。
$ ksh showpid.sh 781
*******************************************
Process has found, pid: 781  ,  addr: 00000017310538B8    
####### Process Information from OS level as below ########
oracle     781     1  0 Jul08 ?        00:00:00 oraclexxxxx (LOCAL=NO)
oracle    5781     1  0 Jun29 ?        00:00:30 oraclexxxxx (LOCAL=NO)
oracle   12210 10679  0 10:29 pts/0    00:00:00 ksh showpid.sh 781
##############################################
       SID    SERIAL# USERNAME        OSUSER          MACHINE              PROCESS         TERMINAL        TYPE
---------- ---------- --------------- --------------- -------------------- --------------- --------------- --------------------
LOGIN_TIME
--------------------------------------
      1409      27981 MIN_BG xxxxx xxxxxxxx           20646           pts/26          USER
2015-07-08 14:58:29
PREV_SQL_ID                    SQL_TEXT
------------------------------ ------------------------------------------------------------
548447mzsjars                  select * from v$version
那么问题就到了第二个session,通过地址映射找不到对应的进程。
$ ksh showpid.sh 36470
*******************************************
Process has found, pid: 36470  ,  addr: 00000017410A2318    
####### Process Information from OS level as below ########
oracle   12251 10679  0 10:29 pts/0    00:00:00 ksh showpid.sh 36470
oracle   36470     1  0 Jul08 ?        00:00:00 oraclexxxxxx (LOCAL=NO)
##############################################
no rows selected
no rows selected

我们手工来理一下这个问题。首先我们知道操作系统级进程，进程号为36470，对应的地址信息为：
SQL> select addr from v$process where spid=36470;
ADDR
----------------
00000017410A2318
我们根据这个地址信息在v$session没有任何收获，所以从v$session映射v$process还是从v$process映射v$session都是断开的链条。
SQL> select sid,serial#,username from v$session where paddr='00000017410A2318';
no rows selected
可以基本断定36470这个进程就是存在问题的进程。
简单和同事进行了确认，然后在操作系统级清理了这个进程。
kill -9 36470
隔了一会，再次查看session,原来显示KILLED状态的session就自动消失了。
$ ps -ef|grep Jul08
oracle     781     1  0 Jul08 ?        00:00:00 oraclexxxxxx (LOCAL=NO)
oracle   15481 10679  0 10:39 pts/0    00:00:00 grep Jul08