清理session的小插曲

前几天在做一次巡检的时候，通过top发现有3个进程占用的时间很长，之前也碰到过几次这种情况，但是排查发现是由于监控程序在运行，算是虚惊一场。 今天看到这些进程的情况，还是不能掉以轻心。

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

2249 xxxxxxxx 25 0 36.5g 3.0g 74m R 100.0 0.9 8949:04 oracleCUST01 (LOCAL=NO)

6579 xxxxxxxx 25 0 36.5g 3.1g 50m R 99.5 0.9 8938:02 oracleCUST01 (LOCAL=NO)

9042 xxxxxxxx 25 0 36.5g 3.1g 28m R 99.5 0.9 8934:51 oracleCUST01 (LOCAL=NO)

先抓出来一个进程，看看到底在干嘛？

>ksh showpid.sh 2249

*******************************************

Process has found, pid: 2249 , addr: 000000089856DEA0

####### Process Information from OS level as below ########

xxxxxxxx 2249 1 99 Mar26 ? 6-05:09:50 oracleCUST01 (LOCAL=NO)

xxxxxxxx 3137 23569 0 16:45 pts/7 00:00:00 ksh showpid.sh 2249

##############################################

SID SERIAL# USERNAME OSUSER MACHINE PROCESS TERMINAL TYPE LOGIN_TIME

---------- ---------- --------------- --------------- -------------------- --------------- ---------------

4471 62525 DB_PRSNL XXXX XXXXLSG_P10-KETNAP 5360:2832 LSG_P10-KETNAP USER 2015-03-26 11:31:52

发现是一个开发人员通过客户端发起的一个查询。这个查询竟然运行了这么长时间。

查看pmon进程的占用时间，已经持续很长时间了。

> ps -ef|grep pmon

xxxxxx 4904 1 2 Feb20 ? 1-00:04:58 ora_pmon_CUST01

这是个很明显的问题，发邮件给客户开发组进行确认，马上得到了反馈，可以Kill这个session

但是客户dba在kill的时候，运行了alter system kill session报了ORA-00031: session marked for kill

查看v$session的状态，发现这几个session都是KILLED状态,看情况就是等待这几个session被清理了。

一个小时之后，我想查看一下这几个session是否已经被清理，发现没有任何变化。

关于kill session其实还有几种选项可用，我们可以使用kill session immediate,disconnect session immediate kill session 命令不会马上清理掉session，在做回滚操作的时候会进行等待，暂时将session标记为KILLED状态，如果使用kill session immediate就有点类似java中进行垃圾回收一样，我们显式声明system.gc(),但是不一定马上进行回收。

 进行disconnect session immediate这种方式会kill掉专用服务连接进程,算是杀伤力较大的一种方式。

但是实际操作的时候发现还是有一定的差距，因为三种方式都不奏效。

SQL> alter system kill session '4471,62525';

alter system kill session '4471,62525'

*

ERROR at line 1:

ORA-00031: session marked for kill

SQL> alter system kill session '4471,62525' immediate;

alter system kill session '4471,62525' immediate

*

ERROR at line 1:

ORA-00031: session marked for kill

SQL> ALTER SYSTEM DISCONNECT SESSION '4471,62525' IMMEDIATE;

ALTER SYSTEM DISCONNECT SESSION '4471,62525' IMMEDIATE

*

ERROR at line 1:

ORA-00031: session marked for kill

这种情况就跟催有些起床困难户起床一样，一波波人赶过去，都败下阵来。

过了一会儿，查看session还是没有任何变化。这个时候只能从操作系统级进行清理了。

不过在清理之前，还是需要先验证一下是否这几个session在做相关的rollback操作。

SET LINESIZE 200

COLUMN username FORMAT A15

SELECT s.username,

s.sid,

s.serial#,

t.used_ublk,

 t.used_urec,

 rs.segment_name,

r.rssize, r.status

FROM v$transaction t,

v$session s,

v$rollstat r,

 dba_rollback_segs rs

WHERE s.saddr = t.ses_addr

AND t.xidusn = r.usn

AND rs.segment_id = t.xidusn

ORDER BY t.used_ublk DESC;

USERNAME    SID      SERIAL# USED_UBLK USED_UREC SEGMENT_NAME          RSSIZE STATUS

        --------------- ---------- ---------- ---------- ---------- ------------------------------ ----------

DBAPPUSER 24787 9155 5 207 _SYSSMU94_2377138680$ 1513996288 ONLINE

DEVTEST 25083 169 3 181 _SYSSMU9_3265824918$ 1601298432 ONLINE

USER_ACCOUNT 3185 2609 3 30 _SYSSMU91_864415611$ 1604444160 ONLINE

DBAPPUSER 5803 28753 3 132 _SYSSMU98_2193874896$ 1584521216 ONLINE

DBAPPUSER 372 1053 3 36 _SYSSMU263_2805064819$ 1732501504 ONLINE

没有发现相关的rollback

在操作系统级进行清理，马上就处理掉了。查看sid为4471的session，发现已经被其它用户使用了。这个问题的解决就告一段落。

SID   SERIAL# USERNAME   OSUSER   MACHINE   PROCESS   TERMINAL   TYPE     LOGIN_TIME    STATUS

---------- ---------- --------------- --------------- -------------------- --------------- ---------------

4471 62529 SECCAPP xxxxx ccbappr13 1234 unknown USER 2015-04-01 16:51:21 INACTIVE

可见这个问题不能掉以轻心，最好还是验证一下session是否已经被清理干净，否则这些资源会一直得不到释放，对系统还是有一定的影响。