enq: TX - row lock contention故障处理一则

Posted 2020-09-25 zhchoutai

一个非常easy的问题，之所以让我对这个问题进行总结。一是由于没我想象的简单，在处理的过程中遇到了一些磕磕碰碰，甚至绕了一些弯路。二是引发了我对故障处理时的一些思考。

6月19日，下午5点左右。数据库出现了大量的enq: TX - row lock contention等待事件，依照以往的经验，这类等待一般与业务逻辑有关。DBA可以做的事情。一般就是将锁等待着的连接信息，等待锁的SQL语句。甚至等待的详细数据行，还有就是锁持有者的连接信息，造成锁等待的SQL语句等一些基本信息提交给开发者，改动业务逻辑。

注意

• 非常多情况下，改动业务逻辑不是一时半会能够马上解决的事，有时候假设锁持有或者锁等待业务不是特别重要。能够与应用维护人员协商，先停掉这部分业务，让其他业务正常执行
• 非常多时候。数据库仅仅有一个锁持有者。并且这个锁持有的连接也没有活动，能够与应用维护人员协商，尝试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 inserted

SQL> 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）基本我们已经确定是什么语句导致锁阻塞，将语句提交给开发者。改动代码后，问题解决！

问题总结

事实上这个问题本身不难。值得思考的是，为什么一个这么简单的问题，无法马上找到原因。说究竟。非常多时候都是经验束缚了我们，在遇到这类问题时。我们须要抛开已有的那些经验。通过数据库的原理来发现根本原因。因此，理论知识再怎么强调都只是分，它真的非常重要。理解了原理，你才干够举一反三。游刃有余，而不是每次一碰到没见过的问题都战战兢兢！