在上周巡检系统的时候发现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的时候还是最好先标示一下绑定的操作系统进程,这样就给事后的处理带来很多的便捷。