子表未创建正确索引导致enq: TM – contention的案例-分析锁机制(子表操作+ON DELETE CASCADE)

继上一篇文章《子表未创建正确索引导致enq: TM – contention的案例-分析锁机制(主表操作)》后,现在来研究子表DML时,在表对象存在主表,子表关系时,子表未创建索引或未创建正确类型索引时(无cascade),会产生什么类型的enq TM的锁类型。

测试表不变:

lock-1-2

测试场景(1)子表insert操作:

同样利用10704 event追踪会话LOCK申请与释放过程,我们可以从TRACE文件中看到,同插入主表操作相同,insert子表也会在主表,子表中申请MODE=3的LOCK

lock2-1

测试场景(2)子表delete操作:子表delete会在主表,子表上各申请MODE=3的LOCK

lock2-2

(3)测试场景3:子表update 操作,同insert,update,主表,子表均会申请MODE=3的LOCK

lock2-3

lock2-5

lock2-4

**************************************************************************************************************下面我们更换测试表,将子表带有delete cascade限制,探究主表子表LOCK模式有何变化:

创建测试表:

lock2-6

测试(1)主表INSERT操作,无变化,主表子表均为MODE=3 TM LOCK;

lock2-7

(2)主表UPDATE操作,同未加ON DELETE CASCADE一致,申请MODE=4的LOCK,马上释放。

lock2-8
lock2-9

(3)主表DELETE操作:我们看到同无ON DELETE CASCADE不同,子表会申请一次MODE=5的SRX锁,并且最后转换为MODE=3的lock,此处便是引发本次故障阻塞的根源。

lock2-10

(4)子表INSERT 操作

同无on delete cascade情况下的子表插入数据,同主表插入数据的情况,子表插入数据同样会申请主表,子表的TM MODE=3的lock

lock2-11

(5)子表UPDATE操作

相同于无on delete cascade情况,子表update数据,会申请主表,子表的TM MODE=3的lock

lock2-12

(6)子表DELETE操作

相同于无on delete cascade情况,子表delete数据,会申请主表,子表的TM MODE=3的lock

lock2-13

总结:

无ON DELETE CASCADE限制,子表操作

(1)子表INSERT:  insert子表也会在主表,子表中申请MODE=3的LOCK

(2)子表update:子表update 操作,同insert,update,主表,子表均会申请MODE=3的                                     LOCK

(3)子表delete:子表delete会在主表,子表上各申请MODE=3的LOCK

含有ON DELETE CASCADE限制:

(1)主表insert:主表INSERT操作,无变化,主表子表均为MODE=3 TM LOCK

(2)主表update:同未加ON DELETE CASCADE一致,申请MODE=4的LOCK,马上释                                  放。

(3)主表delete:我们看到同无ON DELETE CASCADE不同,子表会申请一次MODE=5                                 的SRX锁,并且最后转换为MODE=3的lock

(4)子表insert:同无on delete cascade情况下的子表插入数据,同主表插入数据的情                                    况,子表插入数据同样会申请主表,子表的TM MODE=3的lock

(5)子表delete:相同于无on delete cascade情况,子表delete数据,会申请主表,子                                   表的TM MODE=3的lock

(6)子表update:相同于无on delete cascade情况,子表delete数据,会申请主表,子                                   表的TM MODE=3的lock