暂无图片
enq: TX - row lock contention ---- 为什么锁的是系统的表?
我来答
分享
DER322
2021-12-16
enq: TX - row lock contention ---- 为什么锁的是系统的表?
暂无图片 5M

我们的一个oracle 10g的库io偏高,经过awr分析,最终确定在死锁上面,发现了非常多的enq: TX - row lock contention


通过sql_id去查询,发现sql_text是:

select * from lxFile_02d0ed21 where lxBO=:va and lxFmt=:vb and lxPath=:vc and lxName is null and lxHost=:vd for update

select * from lxBO_02d0ed21 where lxOid=:va for update

select * from lxBO_ef004e68 where lxOid=:va for update

这3个语句都有for update,很容易造成死锁。但这些表我看不懂了

这些表在system下面,分别是:lxFile_02d0ed21,lxBO_02d0ed21,lxBO_ef004e68

这些语句是哪里来的?module显示java.exe,不清楚是怎么产生?


还有这些system下面的表是做什么?怎么解决这个死锁的问题?谢谢!


我来答
添加附件
收藏
分享
问题补充
5条回答
默认
最新
章芋文

查询会话ID为1516,1613的详细信息,另外user_id=57是哪个用户?

暂无图片 评论
暂无图片 有用 0
暂无图片
DER322



看了username,的确是业务用户,通过这个session还有获得什么有用的信息吗?

暂无图片 评论
暂无图片 有用 0
摸摸鱼

既然是业务用户那就让开发去排查程序,为什么要这么干呗。

暂无图片 评论
暂无图片 有用 0
DarkAthena

建议联合这个程序的开发人员进行排查,看是不是程序哪里写得有问题

暂无图片 评论
暂无图片 有用 0
赵勇

1、IO高与锁(死锁是锁的特殊情况,你目前看到的应该是锁,死锁Oracle会自动处理的)通常是前者影响后者。锁发生时,相关会话在队列中等待,此时,应该不会有任何IO操作发生。但IO高,可能导致redo log 写慢,导致发生锁的概率上升。

2、从这些表名看,应该不是系统表。应该是业务表被放到了SYSTEM表空间中。可以查询表中的内容,做进一步的确认。

3、IO高,重点关注AWR报告中按物理读排序的TOPSQL,以及段统计部分中物理读多的对象。

暂无图片 评论
暂无图片 有用 0
回答交流
提交
问题信息
请登录之后查看
邀请回答
暂无人订阅该标签,敬请期待~~
暂无图片墨值悬赏