清理session的小插曲(二) (r6笔记第4天)

在上周巡检系统的时候发现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

通过这个案例可以看出，我们在清理这种进程的时候还是省了不少事情，从操作系统进程的初始化时间缩小了问题分析的范围。然后也是逐个排查，正向反向进行印证，可以基本断定这个存在问题的进程。所以作为问题总结，还是建议在删除session的时候还是最好先标示一下绑定的操作系统进程，这样就给事后的处理带来很多的便捷。