Oracle 数据库发生等待事件:enq: TX - row lock contention ,排查思路

简介: Oracle 数据库发生等待事件:enq: TX - row lock contention ,排查思路

前言

最近看 awr 报告时,经常会看到一些 enq: TX - row lock contention 的等待事件,所以简单研究一下如何排查,仅为个人所见,如有异议或者修正还请评论指出,谢谢!


通常,产生enq: TX - row lock contention事件的原因有以下几种可能:


  • 不同的session更新或删除同一条记录;
  • 唯一索引有重复索引;
  • 位图索引同时被更新或同时并发的向位图索引字段上插入相同字段值;
  • 并发的对同一个数据块上的数据进行update操作;
  • 等待索引块完成分裂;


现象

应用反馈系统使用存在延时,需要排查情况。查看监控服务器,发现数据库存在 enq: TX - row lock contention 锁的情况。


image.png


排查


首先确认发生问题的时间段,然后抓取问题时间段的报告来分析。


AWR 报告


执行 sqlplus / as sysdba @?/rdbms/admin/awrrpt.sql 输入对应时间段的信息,获取 awr 报告。


Top 10 Foreground Events by Total Wait Time

image.png

也可通过 awrcrt sqlplus / as sysdba @awrcrt.sql 来获取多段性能指标信息:

image.png


Segments by Row Lock Waits

通过观察 awr 报告中段的统计信息章节 Segments by Row Lock Waits 项,可以发现发生锁的对象主要是两张表 A 和 B和 A 表的索引:

image.png


与应用确认后,发现其中一张表 A 为核心业务表,暂时怀疑另一张表可能存在问题,这里称之为表 B,所以 A 表暂且不考虑。


SQL ordered by Elapsed Time

通过 🔍 搜索关键字,查出 B 表对应的 UPDATE 语句,执行较为频繁,先记录待查看:


image.png


sql_id 为:2xb71ufa5wmrh。


ASH 报告

抓取对应时间段的 ash 报告,查看是否存在有用信息。


执行 sqlplus / as sysdba @?/rdbms/admin/ashrpt.sql 获取报告:


Top User Events

image.png


Top SQL with Top Events

image.png


Top Blocking Sessions

image.png


Top DB Objects

image.png


从以上信息,不难看出,与 awr 报告分析出的结果吻合,同样的 sql_id 和 对象,并且获取到了 blocking sid。


ADDMRPT 报告

有时,也可以通过抓取 addmrpt 报告来辅助看一下问题,可能有奇效。


执行 sqlplus / as sysdba @?/rdbms/admin/addmrpt.sql 获取 addmrpt 报告:


Summary of Findings

image.png

Finding 2: Row Lock Waits

image.png

同样都指向了 B 表和 sql_id 为 2xb71ufa5wmrh 的这条语句。


应用确认

经过应用确认,该条 sql 是一张核心业务表的一个触发器发起的,业务表每次新增提交时,会去执行该 sql 更新数据。由于未确认该触发器具体作用,因此无法尝试禁用来观察。


写在最后

经过排查,大部分的阻塞都是因为 sql_id 为 2xb71ufa5wmrh 的语句导致,具体也可以通过以以下 sql语句 来进行查询:

select DISTINCT b.sql_id,c.blocked_sql_id
  from DBA_HIST_ACTIVE_SESS_HISTORY b,
       (select a.sql_id as blocked_sql_id,
       a.blocking_session,
               a.blocking_session_serial#,
               count(a.blocking_session)
          from DBA_HIST_ACTIVE_SESS_HISTORY a
         where event like '%enq: TX - row lock contention%'
           and snap_id between 18835 and 18836
         group by a.blocking_session, a.blocking_session_serial#,a.sql_id
        having count(a.blocking_session) > 100
         order by 3 desc) c
 where b.session_id = c.blocking_session
   and b.session_serial# = c.blocking_session_serial#
   and b.snap_id between 18835 and 18836;


需自行替换对应的快照范围 snap_id 值,查询结果 sql_id 为被阻塞,blocked_sql_id 为阻塞 ID。

image.png

📢 如有问题,请及时指正,谢谢!

相关文章
|
2月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
192 64
|
27天前
|
存储 监控 数据处理
flink 向doris 数据库写入数据时出现背压如何排查?
本文介绍了如何确定和解决Flink任务向Doris数据库写入数据时遇到的背压问题。首先通过Flink Web UI和性能指标监控识别背压,然后从Doris数据库性能、网络连接稳定性、Flink任务数据处理逻辑及资源配置等方面排查原因,并通过分析相关日志进一步定位问题。
157 61
|
12天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
48 11
|
25天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
1月前
|
消息中间件 资源调度 关系型数据库
如何在Flink on YARN环境中配置Debezium CDC 3.0,以实现实时捕获数据库变更事件并将其传输到Flink进行处理
本文介绍了如何在Flink on YARN环境中配置Debezium CDC 3.0,以实现实时捕获数据库变更事件并将其传输到Flink进行处理。主要内容包括安装Debezium、配置Kafka Connect、创建Flink任务以及启动任务的具体步骤,为构建实时数据管道提供了详细指导。
79 9
|
17天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
1月前
|
SQL Oracle 关系型数据库
Oracle数据库优化方法
【10月更文挑战第25天】Oracle数据库优化方法
49 7
|
1月前
|
Oracle 关系型数据库 数据库
oracle数据库技巧
【10月更文挑战第25天】oracle数据库技巧
31 6
|
1月前
|
存储 Oracle 关系型数据库
Oracle数据库优化策略
【10月更文挑战第25天】Oracle数据库优化策略
29 5

推荐镜像

更多
下一篇
DataWorks