首页 > 代码库 > enq: TX - row lock contention故障处理一则
enq: TX - row lock contention故障处理一则
一个非常easy的问题,之所以让我对这个问题进行总结。一是由于没我想象的简单,在处理的过程中遇到了一些磕磕碰碰,甚至绕了一些弯路。二是引发了我对故障处理时的一些思考。
注意
- 非常多情况下,改动业务逻辑不是一时半会能够马上解决的事,有时候假设锁持有或者锁等待业务不是特别重要。能够与应用维护人员协商,先停掉这部分业务,让其他业务正常执行
- 非常多时候。数据库仅仅有一个锁持有者。并且这个锁持有的连接也没有活动,能够与应用维护人员协商,尝试kill锁持有者,看看兴许锁等待是否能自己主动解决。
这样的情况通常是一个单独的连接出现僵死导致。kill掉持有者以后,问题自然就攻克了
- 第二种情况就是,前天晚上上线后,平时执行好好的业务,也没出现锁等待。有一天出现了这类问题。并且kill掉锁持有者以后。问题无法得到解决(业务逻辑问题,kill掉以后,兴许还会发生)。这通常是前天晚上上线引起。
本来认为数据库层提供信息非常easy。结果与想象的有点差别,来看一下详细的过程
(1)查询锁信息。例如以下
SESS | LMODE | LMODE | REQUEST | TYPE | EVENT | SQL_TEXT |
Holder: 4266 | exclusive | 6 | 0 | TX | SQL*Net message from client | |
Waiter: 3136 | none | 0 | 4 | TX | enq: TX - row lock contention | insert into xxxxx(ID,xxx,xxxx,xxx,….) values(seq_xxx.nextval,:"SYS_B_0",:"SYS_B_1",:"SYS_B_2",:"SYS_B_3",:"SYS_B_4",:"SYS_B_5") |
Holder: 2276 | exclusive | 6 | 0 | TX | SQL*Net message from client | |
Waiter: 1716 | none | 0 | 4 | TX | enq: TX - row lock contention | insert into xxxxx(ID,xxx,xxxx,xxx,….) values(seq_xxx.nextval,:"SYS_B_0",:"SYS_B_1",:"SYS_B_2",:"SYS_B_3",:"SYS_B_4",:"SYS_B_5") |
Holder: 1288 | exclusive | 6 | 0 | TX | SQL*Net message from client | |
Waiter: 1565 | none | 0 | 4 | TX | enq: TX - row lock contention | insert into xxxxx(ID,xxx,xxxx,xxx,….) values(seq_xxx.nextval,:"SYS_B_0",:"SYS_B_1",:"SYS_B_2",:"SYS_B_3",:"SYS_B_4",:"SYS_B_5") |
Holder: 1000 | exclusive | 6 | 0 | TX | SQL*Net message from client | |
Waiter: 1147 | none | 0 | 4 | TX | enq: TX - row lock contention | insert into xxxxx(ID,xxx,xxxx,xxx,….) values(seq_xxx.nextval,:"SYS_B_0",:"SYS_B_1",:"SYS_B_2",:"SYS_B_3",:"SYS_B_4",:"SYS_B_5") |
Holder: 2989 | exclusive | 6 | 0 | TX | SQL*Net message from client | |
Waiter: 862 | none | 0 | 4 | TX | enq: TX - row lock contention | insert into xxxxx(ID,xxx,xxxx,xxx,….) values(seq_xxx.nextval,:"SYS_B_0",:"SYS_B_1",:"SYS_B_2",:"SYS_B_3",:"SYS_B_4",:"SYS_B_5") |
备注:表名和列名做了模糊化
能够看到,锁等待语句正在等待Insert条记录
(2)通过查看锁持有者,已经运行的语句,来推断究竟是那个语句造成了锁等待,查询语句例如以下:
select b.sql_text ,a.* from v$open_cursor a,v$sql b where a.sql_id=b.sql_id and a.sid=4266 and upper(b.sql_text) like ‘%xxxxx%‘;
(3)
依据经验insert一条语句被堵塞,通常是因为主键约束引起(还有一个连接也插入了同一条语句或者删除了一条语句,可是没有提交)
可是我通过上面的语句查询的时候。发现怎么也找不到锁持有者有运行过这个表的不论什么DML,并且询问开发者,他们也说没有对这张表的DML操作
当中open_cursor为1000,v$open_cursor中的记录也远远没有达到这个数,才100条不到。
session_cached
_cursors设置为200。没有道理这个连接运行的语句游标已经被刷新出去(4)还真没有遇到过类似的问题。怎么也找不到。这时我换了一个想法。抛开那些经验。我在想,是不是有一种可能不正确Insert插入语句进行不论什么DML操作,也会造成一条插入语句被锁掉??
我考虑了这张表的依赖对象是不是会造成种类等待,比如触发器、外键引用等等。
细致考虑一番,发现触发器,审计什么的,数据库应该能定位到详细的语句,而不是发生在这个insert语句本身(就算是递归语句。Oracle也能捕获到才对),因此,最让我怀疑的就是外键引用。通过以下这个查询。推断是否这个表通过外键引用了其它对象,例如以下
select a.table_name,
a.owner,
a.constraint_name,
a.constraint_type,
a.r_owner,
a.r_constraint_name,--被外键引用的约束名
b.table_name --被外键引用的表名
from dba_constraints a, dba_constraints b
where a.constraint_type = ‘R‘
and a.r_constraint_name = b.constraint_name
and a.r_owner = b.owner
and b.table_name = ‘xxxxx‘
and b.owner=‘‘;
查询发现,确实有一张表引用这个插入等待的表,这时,顿时感觉希望非常大。
(5)通过一个简单的測试,我验证我的猜測。例如以下
create table t3 (id number primary key,name varchar2(20),product_id number);
create table t2 (id number primary key,name varchar2(20));
alter table t3 add constraint FK_PRODUCTSTAT_PRODUCTID foreign key (PRODUCT_id) references t2 (ID);
SQL> insert into t2 values(1,‘dh‘);
1 row inserted
SQL> insert into t2 values(2,‘cc‘);
1 row inserted
SQL> insert into t2 values(3,‘cc‘);
1 row insertedSQL> commit;
Commit complete
session 1运行例如以下操作:
SQL> select * from t2;
ID NAME
---------- --------------------
1 dh
2 cc
3 cc
SQL> select * from t3;
ID NAME PRODUCT_ID
---------- -------------------- ---------- --能够看到,这时t3表有不论什么记录
SQL> insert into t2 values(4,‘cc‘); --对父表运行一条插入
1 row inserted、session2 t2表运行一条插入操作,例如以下
insert into t3 values(1,‘tt‘,4);
令人惊喜的是,确实发生了锁等待。与我们遇到的锁等待类型一模一样。
(6)查询锁持有者。是否有对锁等待表的父表有进行DML操作。例如以下
select b.sql_text ,a.* from v$open_cursor a,v$sql b where a.sql_id=b.sql_id and a.sid=4266 and upper(b.sql_text) like ‘%xxxxx_ref%‘;
检查结果与我们预期的一致,确实有非常多对主表的插入操作!
(7)基本我们已经确定是什么语句导致锁阻塞,将语句提交给开发者。改动代码后,问题解决!
问题总结
事实上这个问题本身不难。值得思考的是,为什么一个这么简单的问题,无法马上找到原因。说究竟。非常多时候都是经验束缚了我们,在遇到这类问题时。我们须要抛开已有的那些经验。通过数据库的原理来发现根本原因。因此,理论知识再怎么强调都只是分,它真的非常重要。理解了原理,你才干够举一反三。游刃有余,而不是每次一碰到没见过的问题都战战兢兢!
enq: TX - row lock contention故障处理一则
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。