1 、故障描述

某次，接到用户电话反馈，某核心数据库在3 点多锁非常多，已经严重影响业务，紧急协调用户杀了相关会话后数据库正常。但需要对锁产生的深层次原因进行排查。

故障的整体现象表现为数据库存在 enq: TM - contention 等待事件，业务不能正常进行。

2 、根因分析

远程登录到客户环境，通过分析 AWR 报告发现数据库两个节点的 DB_TIME 比较高， enq: TM - contention 等待 1 节点时间占到 db_time 的 82% 以上， enq: TM - contention 等待 2 节点时间占到 db_time 的 73% 以上。

1 节点：

2 节点：

通过查看 SQL ordered by Elapsed Time 发现 TM 锁主要集中在 TAB1 表。

通过查询 dba_hist_active_sess_history 表对历史等待进行分析

select INSTANCE_NUMBER,

SESSION_ID,

SQL_ID,

WAIT_CLASS,

PROGRAM,

MACHINE,

EVENT,

BLOCKING_SESSION,

TIME_WAITED / 1000000 TIME_WAITED,

CURRENT_OBJ#

from dba_hist_active_sess_history

where SAMPLE_TIME between

TO_TIMESTAMP('2021-09-15 15:00:00', 'YYYY-MM-DD HH24:MI:SS') and

TO_TIMESTAMP('2021-09-15 15:40:00', 'YYYY-MM-DD HH24:MI:SS')

and TIME_WAITED > 0

order by 9;

会话当前使用的对象 ID 为 89951 ，查看 89951 是什么对象，为 TAB2 表。

查看 TAB2 的建表语句。

通过建表语句可以发现 TAB2 有外键约束引用 TAB1 表的 ID 列，当外键无索引时，更新删除主表的数据会造成子表的锁定，但如果此时子表上有事务，那么进行更新删除的 session 变会等待，等待事件就是 enq: TM – contention ，检查外键表索引情况。

由于 TAB2 表上 XXX_ID 列没有索引导致 TM – contention 。因此，建议在子表 TAB2 的 XXX_ID 列创建索引，在业务低峰的时间进行操作。