Oracle RAC环境下如何定位并杀掉最终阻塞的会话
导读:Oracle RAC环境下定位并杀掉最终阻塞的会话,本文通过一个测试demo来具体介绍。
实验环境:
Oracle RAC 11.2.0.4 (2节点)
1.模拟故障:会话被级联阻塞
2.常规方法:梳理找出最终阻塞会话
3.改进方法:立即找出最终阻塞会话
但上文给出的例子过于简单,实际对于生产中复杂的阻塞问题,一步步找最终阻塞就比较麻烦。所以本篇旨在寻求更好更快捷的办法。
1. 模拟故障:会话被级联阻塞
准备工作:
我这里在每个实例开两个会话来模拟RAC在负载均衡模式下的业务会话:
实例1:会话1,会话2;
实例2:会话3,会话4;
在 时间点1 -> 时间点2 -> 时间点3 -> 时间点4 的这个时间轴上分别执行以下操作:
时间点1:
在实例1的会话1(INS1-session1)执行语句未提交或回滚:
select * from v$mystat where rownum = 1;update emp set sal = 8000 where empno = 7788;
时间点2:
在实例2的会话3(INS2-session3)执行语句:
select * from v$mystat where rownum = 1;delete from emp where empno = 7839;update emp set job = 'MANAGER' where empno = 7788;rollback;
时间点3:
在实例2的会话4(INS2-session4)执行语句:
select * from v$mystat where rownum = 1;update emp set sal = 15000 where empno = 7839;rollback;
时间点4:
在实例1的会话2(INS1-session2)执行语句:
select * from v$mystat where rownum = 1;update emp set job = 'CEO' where empno = 7839;rollback;
此时可以看到,在后面3个时间点进行操作的会话均hang住,显然都是被阻塞了。4个会话的现象如下:
那么他们究竟都是被谁阻塞了呢?下文会详细分析。
2.常规方法:梳理找出最终阻塞会话
我们常规会去GV$SESSION查询blocking_session,再看这个blocking_session有没有又被其他会话阻塞,直到找到根源。
--blockingset lines 180col program for a30col machine for a20select inst_id, SID, SERIAL#, event, machine, sql_id, blocking_session, blocking_instance from gv$session where blocking_session is not null;
结果如下:
SYS@jyzhao1 >--blockingSYS@jyzhao1 >set lines 180SYS@jyzhao1 >col program for a30SYS@jyzhao1 >col machine for a20SYS@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 blockingset lines 200 pages 100col tree for a30col event for a40select * 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$sessionselect * 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$sessionSYS@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$sessionSYS@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 >
至此,就达到了我们在RAC环境中快速定位并杀掉这种最终阻塞会话的目的。
墨天轮原文链接:https://www.modb.pro/db/21859(复制到浏览器中打开或者点击左下角的“阅读原文”)
推荐阅读:144页!分享珍藏已久的数据库技术年刊
点击下图查看更多 ↓
云和恩墨大讲堂 | 一个分享交流的地方
长按,识别二维码,加入万人交流社群
请备注:云和恩墨大讲堂
点个“在看”
你的喜欢会被看到❤
Oracle RAC环境下如何定位并杀掉最终阻塞的会话相关推荐
- Oracle RAC 环境下的连接管理(转) --- 防止原文连接失效
崔华老师的文章!!! 这篇文章详细介绍了Oracle RAC环境下的连接管理,分别介绍了什么是 Connect Time Load Balancing.Runtime Connection Load ...
- Oracle RAC 环境下的连接管理
转自 http://www.oracle.com/technetwork/cn/articles/database-performance/oracle-rac-connection-mgmt-165 ...
- Oracle RAC环境下如何更新patch(Rolling Patch)
Oracle RAC数据库环境与单实例数据库环境有很多共性,也有很多异性.对于数据库补丁的更新同样如此,都可以通过opatch来完成.但RAC环境的补丁更新有几种不同的更新方式,甚至于可以在零停机的情 ...
- Oracle rac环境下数据文件误建在本地目录的处理过程
错误描述 Mon Nov 16 19:02:38 2015 Errors in file /u01/app/oracle/diag/rdbms/zwzwdb/zwzwdb1/trace/zwzwd ...
- oracle rac环境下修改1521集群端口
文章目录 一.修改前准备工作 1.确认端口是否占用 2.grid确认监听状态以及名称 二.grid修改集群端口 1.grid修改监听端口 2.grid修改scan监听端口 3.双节点确认实例下loca ...
- oracle rac 磁盘重建,Oracle RAC环境下重建ASM磁盘组 Re-create ASM diskgroup with Oracle RAC...
oracle@node01:/$dbca 查看创建结果: 16)最后,引用原文如下: Steps to Re-Create ASM Diskgroups [ID 268481.1] 修改时间 17-M ...
- Oracle RAC 环境数据备份与恢复实践
[导读]某企业因项目需要在Oracle RAC集群环境下,根据实际情况对Oracle数据库进行备份:使用生产环境的rman全备数据,进行恢复数据搭建测试环境.本文将详细介绍此案例中Oracle数据库r ...
- 死锁oracle rac,利用LOGMINER进行RAC环境下的死锁分析——转载
RAC中的死锁的判断机制跟单机很不相同,比单机要复杂的多,而且消耗的时间和资源也比单机要多的多,所以亚马逊的DBA TEAM曾经在一份经验总结中指出如果是并发非常大的OLTP系统,如果锁的问题处理不好 ...
- 分析解决11gR2 双节点RAC环境下的gc cr block busy/gc buffer busy acquire等待
? 系统环境 两节点的RAC:AIX6.1+Oracle 11.2.0.3.3 ? AWR里展示出来的各种症状(数据来自实例2) 虽然应用没有报障,但AWR报告里的各种迹象已经很明显了 (1) ...
最新文章
- 新版CCNP中文版教材--ISCW
- Python全栈开发——描述符
- 如何下载图片新闻并将其写入文件
- jquery $.each()函数编程实例五则图解
- java 协程框架_GitHub - yaozhang0105/dactor: Dactor是基于Java的轻量级同步异步统一处理框架,基于协程思想构建...
- Apache PHP-fpm Mariadb
- 一键复制android代码,兼容安卓和ios实现一键复制内容到剪切板
- 关于SIGPIPE导致的程序退出
- java getidentifier_android – 如何使用getResource.getIdentifier()获取布局?
- 学汉语、来云栖、海外布道阿里云……这位印度架构师不一般
- freeswitch 配置动态会议的注意事项
- mysql导入.sql文件中文乱码_mysql通过sql文件导入数据时出现乱码的解决办法
- distpicker省市区插件设置请选择省市区提示/或设置初始值问题
- Centos7+搜狗拼音输入法 安装不踩雷
- 基于JAVA小小银动漫网站计算机毕业设计源码+数据库+lw文档+系统+部署
- 国美云运维自动化实践
- 自定制shell提示符
- 「三代组装」使用Pilon对基因组进行polish
- PMP 项目管理(12)项目采购管理 思维导图 解读
- pythondocumentation_python官方文档