清理session的小插曲(r4笔记第95天)

前几天在做一次巡检的时候,通过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            XXXX\LSG_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是否已经被清理干净,否则这些资源会一直得不到释放,对系统还是有一定的影响。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-04-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

由一条报警信息发现的一系列问题(r7笔记第67天)

今天看到一条报警短信,提示是某个表空间的问题。 ZABBIX-监控系统: ------------------------------------ 报警内容:...

37490
来自专栏杨建荣的学习笔记

一个慢查询报警的简单处理 (r8笔记第12天)

今天在做节后的一个基本检查的时候,发现一个不太起眼的报警,报警内容为大体为: MySQL 每秒慢查询次数超过 <1>个on xxxx 查看zabbix的监控数...

38080
来自专栏杨建荣的学习笔记

备库跳归档恢复的有趣案例(r9笔记第19天)

在Data Guard环境中,主备库基本都是使用归档来传递数据的变化。如果主备的归档传输中断,同时主库的归档被删除或者损坏,这种情况下备库是没法开始继续...

34850
来自专栏杨建荣的学习笔记

一次数据库宕机问题的分析(r6笔记第5天)

今天来到办公室,发现有一台服务器中的数据库实例停掉了。这种情况真是意料之外,尤其是我还不是很熟悉这台机器的服务。 赶紧查看数据库日志,可以看到数据库在昨晚停掉了...

50050
来自专栏乐沙弥的世界

SHUTDOWN: Active processes prevent shutdown operation

      在使用shutdown immediate关闭数据库时hang住,查看alert 日志,遭遇了SHUTDOWN: Active processes ...

10320
来自专栏杨建荣的学习笔记

关于生产系统锁问题的排查(r3笔记第79天)

今天生产系统中的一个daemon出现了严重的数据处理延迟,客户需要我们立即给出处理的方案。在综合评估之后,为了不保证在线业务延迟,开发部门给出了临时的解决意见。...

30550
来自专栏数据和云

Oracle 18.3 : 透过告警日志从安装初始化过程看 18c 的新改变

Oracle Database 18c 已经正式对外发布,第一个公共版本的版本号是 18.3 ,让我们从 18.3 的安装过程来一睹 18c 的改变。

10900
来自专栏乐沙弥的世界

记一次奇怪的ORA-04028: cannot generate diana for object

      开发人员说新建了一个package,在编译的过程中出现了一些错误。提示为PL/SQL:ORA-00942: table or view does n...

6710
来自专栏杨建荣的学习笔记

一条sql语句导致的数据库宕机问题及分析(42天)

之前分享过一篇博文,是一条sql语句"导致"的数据库宕机,上次是另有原因,这次真碰到一个案例,而且是在重要的环境上,希望大家引以为戒。 数据库是基于Linux6...

34550
来自专栏沃趣科技

ASM 翻译系列第十八弹:ASM Internal ASM file number 5

原作者:Bane Radulovic 译者: 魏兴华 审核: 魏兴华 ASM file number 5 本章讲述ASM的5号文件,5号文件是ASM...

36660

扫码关注云+社区

领取腾讯云代金券