深入剖析：insert 的enq: TM – contention

Lunar 拥有超过十年的 ORACLE SUPPORT 从业经验，曾经服务于ORACLE ACS部门，现就职于 ORACLE Sales Consultant 部门，负责的产品主要是 Exadata，Golden Gate，Database 等。

编辑手记：此文通过分场景环环紧扣的测试，深入剖析了enq: TM – contention等待事件的原理，今日拣选与大家共享。

结论：当外键无索引时

1，对子表的insert操作所在的事务没有完成前，对于父表的DML操作（INSERT/UPDATE/DELETE）都会因为不能获得对子表的TM锁而出现enq: TM – contention。
2，在1的基础上，如果又有了对子表的insert，那么这个对子表的insert同样被阻塞，等待事件也是 enq: TM – contention。
3，对父表的insert会阻塞对父表的delete。同样的道理，此时对父表的insert也阻塞对父表的update pk操作。

当没有索引的时候

测试1, 在子表发生 Insert，然后在父表上有update操作

Session 1: 对子表进行insert，不commit时：

这是，我们看到，该回话在主表（1062788 DEPT）和子表（1062790 EMP）上都分别持有了 exclusive lock(LMODE=3)锁

同时，该回话还持有一个tx锁（在子表 emp上）

另开一个会话，观察锁：

Session 2 : 然后，我们在父表做DML操作update:

Session 3: 检查锁的变化

这是我们看到，Session 2 在子表（1062790 EMP）上请求LMODE=4，并在主表（1062788 DEPT）上持有等待：enq: TM – contention

这是很清晰，有blocker了，也就是Session 1（SID 321），此时该回话正在对子表（1062790 EMP）进行插入操作.

换句话说，当外键无索引时，对子表的insert操作，会造成对父表的更新操作的阻塞。

Session 4 更新父表：

这是我们看到，session 4（sid 116）遵循了跟session 220同样的所规律

这是我们在Session 1中执行commit，在Session 3中观察：

可以看到Session 2和Session 4都完成了update：
Session 2：

这里我们看到，当外键无索引时，对子表的insert操作，会造成对父表的更新操作的阻塞，该阻塞直到子表的insert事务结束，才自动释放。

测试2, 在子表发生 Insert，然后在父表上有update操作，然后再有一个会话对子表做insert

重复上面的操作，不对session 1进行commit时，再开一个窗口（Session 5）对子表做insert

这是我们看到，对于子表的insert语句被阻塞了。

在Session 3中观察:

这里我们看到：
1，当外键无索引时，对子表的insert操作，会造成对父表的更新操作的阻塞，该阻塞直到子表的insert事务结束，才自动释放。
2，如果对子表有insert操作，在这个insert所在事务没有commit之前，有对父表的update，那么接下来的对子表的inser会被阻塞

测试3：

在测试2的场景上，将session 2和session 4中的对父表的update执行Ctrl+C，然后分别改为INSERT 和delete 父表（dept）的操作，观察一下
Session 4：

Session 5 随之自动解锁，并报了正常的违反约束的错误：

在session 2中执行delete 父表的操作：

注意：
1，delete父表的操作被阻塞，依然是正在请求以LMODE=4的模式对子表（1062790 EMP）的TM锁
2，这里的sid 222中为非活动会话，当该回话执行了commit或者rollback后，这个Insert的“SQL*Net message from client”等待就会消失了。

测试4： 在测试3的场景上，继续session 4中的对父表做insert 的操作，观察一下

Session 4：

这里我们看到，虽然Session 4执行的是对父表的insert，session 2执行的是对父表的 delete，他们的表现跟update的表现都是相同的。也就是说，对于子表的insert操作所在的事务没有完成前，对于父表的DML操作（INSERT/UPDATE/DELETE）都会因为不能获得对子表的TM锁而出现enq: TM – contention

测试5： 在测试4的基础上，我们在Session 1对做commit，完成对子表的insert操作，然后观察其他session：

Session 1：

Session 4：对父表的insert插入操作随着session 1的commit 自动解锁：

Session 2（SID 220）：对父表的delete操作依然是hang的状态：

也就是说，这里我们看到了，对父表的insert，阻塞了对父表的delete