Oracle RAC环境下定位并杀掉最终阻塞的会话方法是什么

技术Oracle RAC环境下定位并杀掉最终阻塞的会话方法是什么本篇内容介绍了“Oracle RAC环境下定位并杀掉最终阻塞的会话方法是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带

本文介绍了“在Oracle RAC环境中定位和终止最终被阻止的会话的方法是什么”的知识。很多人在实际案例的操作中会遇到这样的困难。让边肖带领你学习如何处理这些情况。希望大家认真阅读,学点东西!

实验环境:

甲骨文RAC 11.2.0.4(2个节点)

1.模拟失败:会话被级联阻止。

2.常规方法:梳理出最后阻塞的会话。

3.改进方法:立即找出最后阻塞的会话。

其实我之前也写过一篇相关的文章:

如何定位Oracle数据库锁定会话的根目录?

1.模拟故障:会话被级联阻塞

准备工作:

在这里,我在每个实例中打开两个会话来模拟负载平衡模式下RAC的业务会话:

示例:会话1,会话2;

示例2:会话3,会话4;

从时间点1-时间点2-时间点3-时间点4在此时间轴上执行以下操作:

时间点1:

实例1的会话1(INS1-session1)中的执行语句未提交或回滚:

选择* frov $ mystatwhrownum=1;

updateempsetsal=8000 where empno=7788;时间点2:

执行实例2的会话3(INS2-session3)中的语句:

选择* frov $ mystatwhrownum=1;

deletefromempwhereempno=7839

updateempsetjob=' MANAGER ' where empno=7788;

回滚;时间点3:

执行实例2的会话4(INS2-session4)中的语句:

选择* frov $ mystatwhrownum=1;

updateempsetsal=15000 where empno=7839;

回滚;时间点4:

在实例1的会话2(INS1-session2)中执行语句:

选择* frov $ mystatwhrownum=1;

updateempsetjob=' CEO ' where empno=7839;

回滚;这时可以看到,接下来三个时间点操作的会话都挂了,明显是被屏蔽了。4节课的现象如下:

Oracle  RAC环境下定位并杀掉最终阻塞的会话方法是什么

Oracle  RAC环境下定位并杀掉最终阻塞的会话方法是什么

Oracle  RAC环境下定位并杀掉最终阻塞的会话方法是什么

Oracle  RAC环境下定位并杀掉最终阻塞的会话方法是什么

那么他们被谁挡住了呢?下面将详细分析。

00-1010,我们会去GV$SESSION查询blocking_session,然后看这个blocking_ses。

sion有没有又被其他会话阻塞,直到找到根源。

--blocking
set lines 180
col program for a30
col machine for a20
select inst_id,
       SID,
       SERIAL#,
	   event,
	   machine,
       sql_id,
       blocking_session,
       blocking_instance
  from gv$session
 where blocking_session is not null;

结果如下:

SYS@jyzhao1 >--blocking
SYS@jyzhao1 >set lines 180
SYS@jyzhao1 >col program for a30
SYS@jyzhao1 >col machine for a20
SYS@jyzhao1 >select inst_id,
  2         SID,
  3         SERIAL#,
  4        event,
  5        machine,
  6         sql_id,
  7         blocking_session,
  8         blocking_instance
  9    from gv$session
 10   where blocking_session is not null;
   INST_ID        SID    SERIAL# EVENT                                    MACHINE              SQL_ID        BLOCKING_SESSION BLOCKING_INSTANCE
---------- ---------- ---------- ---------------------------------------- -------------------- ------------- ---------------- -----------------
         1        146       6283 enq: TX - row lock contention            jyrac1               052gy77vp276s               25                 2
         2         25      10250 enq: TX - row lock contention            jyrac2               3t2npbvdcf2d2              150                 1
         2        145      32069 enq: TX - row lock contention            jyrac2               0ct116qw46shq               25                 2
SYS@jyzhao1 >

可以看到实例1的sid=146的会话以及实例2的sid=145的会话都被实例2的sid=25的会话阻塞,而实例2的sid=25的这个会话又被实例1的sid=150的会话阻塞。这个例子只模拟了几个会话尚且可以快速定位,但如果是真实故障,很可能受影响的不止这么几个会话,虽然也可以慢慢最终找出来,但毕竟会看的眼花缭乱是不是。我们高傲的DBA又怎么会甘心一直去做这种事情呢?

3.改进方法:立即找出最终阻塞会话

之前我在单实例或者确认业务只跑在某一个节点的环境,一直在用的一个找出最终阻塞会话的脚本:

--cascade blocking
set lines 200 pages 100
col tree for a30
col event for a40
select *
  from (select a.sid, a.serial#,
               a.sql_id,
               a.event,
               a.status,
               connect_by_isleaf as isleaf,
               sys_connect_by_path(SID, '<-') tree,
               level as tree_level
          from v$session a
         start with a.blocking_session is not null
        connect by nocycle a.sid = prior a.blocking_session)
 where isleaf = 1
 order by tree_level asc;

这个脚本用到了start with connect by prior 的递归查询用法,非常方便可以直接找出最终阻塞的会话;可如果是RAC,业务是负载均衡跑在多个节点的,那上面的这个脚本就不好用了,比如我上面构造的这个例子,就需要明确查出各个会话分别在哪个实例上,否则你怎么确认去哪里杀呢,怎么办呢?其实也简单,只需要稍加改动下这个脚本即可,改后如下:

--cascade blocking@gv$session
select *
  from (select a.inst_id, a.sid, a.serial#,
               a.sql_id,
               a.event,
               a.status,
               connect_by_isleaf as isleaf,
               sys_connect_by_path(a.SID||'@'||a.inst_id, ' <- ') tree,
               level as tree_level
          from gv$session a
         start with a.blocking_session is not null
        connect by (a.sid||'@'||a.inst_id) = prior (a.blocking_session||'@'||a.blocking_instance))
 where isleaf = 1
 order by tree_level asc;

结果如下:

SYS@jyzhao1 >--cascade blocking@gv$session
SYS@jyzhao1 >select *
  2    from (select a.inst_id, a.sid, a.serial#,
  3                 a.sql_id,
  4                 a.event,
  5                 a.status,
  6                 connect_by_isleaf as isleaf,
  7                 sys_connect_by_path(a.SID||'@'||a.inst_id, ' <- ') tree,
  8                 level as tree_level
  9            from gv$session a
 10           start with a.blocking_session is not null
 11          connect by (a.sid||'@'||a.inst_id) = prior (a.blocking_session||'@'||a.blocking_instance))
 12   where isleaf = 1
 13   order by tree_level asc;
   INST_ID        SID    SERIAL# SQL_ID        EVENT                                    STATUS       ISLEAF TREE                           TREE_LEVEL
---------- ---------- ---------- ------------- ---------------------------------------- -------- ---------- ------------------------------ ----------
         1        150       8742               SQL*Net message from client              INACTIVE          1  <- 25@2 <- 150@1                       2
         1        150       8742               SQL*Net message from client              INACTIVE          1  <- 145@2 <- 25@2 <- 150@1              3
         1        150       8742               SQL*Net message from client              INACTIVE          1  <- 146@1 <- 25@2 <- 150@1              3
SYS@jyzhao1 >

非常清晰可以看到最终阻塞其他会话的会话是实例1的sid=150,serial#=8742的会话。
那么与相关人员都确认后,就可以直接杀掉这个最终阻塞会话:

SYS@jyzhao1 >alter system kill session '150,8742' immediate;
System altered.

再次查询,恢复正常,不再有堵塞了:

SYS@jyzhao1 >--cascade blocking@gv$session
SYS@jyzhao1 >select *
  2    from (select a.inst_id, a.sid, a.serial#,
  3                 a.sql_id,
  4                 a.event,
  5                 a.status,
  6                 connect_by_isleaf as isleaf,
  7                 sys_connect_by_path(a.SID||'@'||a.inst_id, ' <- ') tree,
  8                 level as tree_level
  9            from gv$session a
 10           start with a.blocking_session is not null
 11          connect by (a.sid||'@'||a.inst_id) = prior (a.blocking_session||'@'||a.blocking_instance))
 12   where isleaf = 1
 13   order by tree_level asc;
no rows selected
SYS@jyzhao1 >

“Oracle RAC环境下定位并杀掉最终阻塞的会话方法是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站,小编将为大家输出更多高质量的实用文章!

内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/68679.html

(0)

相关推荐

  • 抖音买10个赞自助下单平台,免费抖音下单网站?

    技术抖音买10个赞自助下单平台,免费抖音下单网站?抖音业务自助下单刷平台为明星、网红和企业提供抖音刷粉丝,抖音买粉丝,抖音买赞,抖音刷赞,抖音刷粉,抖音权限开通,抖音上热门等抖音服务,我们不同于其他网站,我们只做效率快的

    测评 2021年11月11日
  • 2021-2022-1 20211307《信息安全专业导论》第九周学习总结

    技术2021-2022-1 20211307《信息安全专业导论》第九周学习总结 2021-2022-1 20211307《信息安全专业导论》第九周学习总结2021-2022-1 20211307《信息安

    礼包 2021年11月20日
  • Python脚本程序与Perl怎么进行比较

    技术Python脚本程序与Perl怎么进行比较Python脚本程序与Perl怎么进行比较,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。Python脚本程序在

    攻略 2021年10月28日
  • C++ socket网络编程方法是什么

    技术C++ socket网络编程方法是什么本篇内容主要讲解“C++ socket网络编程方法是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“C++ socket网络编程方

    攻略 2021年11月19日
  • 美女生日祝福语八个字,朋友生日祝福语,女性简短八个

    技术美女生日祝福语八个字,朋友生日祝福语,女性简短八个1.生日快乐,永远美丽美女生日祝福语八个字!2.今天,你是最美丽的,美好的生日祝福,送给你,美丽的生日礼物,送给你3.时间的轮回让我们陪伴着你过了一个又一个的生日,看

    生活 2021年10月28日
  • java-异常-异常注意事项

    技术java-异常-异常注意事项 java-异常-异常注意事项1 package p1.exception;2 3 /*4 * 异常的注意事项:5 * 6 * 1,子类在覆盖父类方法时,父类的方法

    礼包 2021年11月5日