enq: TM - contention 几乎总是外键列未建索引所致：主表DML时需全表扫描子表校验引用，触发子表级TM锁（MODE=4），与子表上正在进行的DML（MODE=3）不兼容而阻塞；通过ASH查P2得object_id，反查dba_objects定位被锁子表，再结合dba_constraints与dba_ind_columns验证外键列是否缺失匹配索引。
enq: tm - contention 几乎总是外键列没建索引导致的，尤其在主表 dml 时卡住子表操作——不是“可能”，是大概率根因。
查 P2 对象 ID 定位被锁的子表
等待事件里的 P2 字段就是关键线索：它不是文件号或块号，而是被锁对象的 object_id。直接查 v$active_session_history 或历史 dba_hist_active_sess_history 过滤 event = 'enq: TM - contention'，取出 P2 值，再用 dba_objects 反查对应表名：
SELECT object_name, object_type FROM dba_objects WHERE object_id = &p2_value;
常见误判点：
- 如果你正在操作 ORDERS 表，但 P2 指向的是 ORDER_ITEMS，那问题就在子表上；
- 若子表是分区表，P2 指向的是分区级对象（如 OBJECT_TYPE = 'TABLE PARTITION'），需确认索引是否为 LOCAL 且覆盖所有分区；
- 不要查 dba_data_files，P2 和数据文件完全无关。
验证外键约束与索引列是否匹配
找到疑似子表后，确认它的外键列有没有被索引覆盖。注意：索引列顺序、前导列、是否包含全部外键列都影响有效性。
- 外键列是
(order_id, product_id)，但现有索引只建在(product_id)或(order_id, status)——不匹配，仍会触发全表扫描 - 复合外键必须索引列顺序一致、且前导列完全相同；
(a,b)外键不能靠(b,a)索引缓解 - 唯一索引（
UNIQUE）或主键索引可复用，但普通非唯一索引必须显式创建
快速检查语句（按用户范围）：
SELECT c.table_name, cc.column_name, cc.position
FROM user_constraints c, user_cons_columns cc
WHERE c.constraint_name = cc.constraint_name
AND c.constraint_type = 'R'
AND c.owner = cc.owner
AND c.owner = UPPER('&owner')
MINUS
SELECT i.table_name, ic.column_name, ic.column_position
FROM user_indexes i, user_ind_columns ic
WHERE i.index_name = ic.index_name
AND i.owner = ic.owner
AND i.owner = UPPER('&owner');生成并执行缺失索引 DDL
手动拼写索引名容易出错，建议用脚本生成标准 CREATE INDEX 语句。注意加 ONLINE 避免阻塞业务，但 11g 中 ONLINE 不支持 UNIQUE 索引重建，且需额外空间。
- 索引名建议统一前缀，比如
idx_fk_<table>_<col1>，避免和已有索引冲突<li>如果外键列允许 NULL，非唯一索引即可；若业务强依赖外键一致性，优先建 <code>NOT NULL约束 + 索引 - 对大表建索引前，先在测试环境跑
EXPLAIN PLAN确认执行计划走索引，而非继续全扫
示例生成语句（适配 11g）：
SELECT 'CREATE INDEX idx_fk_' || c.table_name || '_' || c.columns || ' ON ' || c.table_name || '(' || c.columns || ') ONLINE NOLOGGING;' ddl
FROM (
SELECT a.table_name,
MAX(DECODE(a.position, 1, a.column_name, NULL)) ||
MAX(DECODE(a.position, 2, ',' || a.column_name, NULL)) ||
MAX(DECODE(a.position, 3, ',' || a.column_name, NULL)) columns
FROM user_cons_columns a, user_constraints b
WHERE a.constraint_name = b.constraint_name
AND b.constraint_type = 'R'
AND a.owner = b.owner
AND a.owner = UPPER('&owner')
GROUP BY a.table_name, b.constraint_name
) c
WHERE NOT EXISTS (
SELECT 1 FROM user_ind_columns ic, user_indexes i
WHERE i.table_name = c.table_name
AND i.index_name = ic.index_name
AND i.owner = ic.owner
AND ic.column_name IN (SELECT column_name FROM user_cons_columns ucc
WHERE ucc.constraint_name IN (
SELECT constraint_name FROM user_constraints
WHERE table_name = c.table_name AND constraint_type = 'R'
))
AND ic.column_position <= (
SELECT COUNT(*) FROM user_cons_columns ucc2
WHERE ucc2.constraint_name IN (
SELECT constraint_name FROM user_constraints
WHERE table_name = c.table_name AND constraint_type = 'R'
)
)
);建完索引后仍卡？检查事务和锁链
索引建好不等于问题立刻消失——旧事务持有的锁还在。必须主动清理残留阻塞：
- 查
v$lock找到LMODE = 3（RX）或LMODE = 4（SRX）且REQUEST > 0的会话，重点关注BLOCK = 1的 blocker - 用
v$session关联查SQL_ID和EVENT，确认 blocker 是否仍在执行未提交的子表 DML - 11g 中无法自动释放已建索引后的锁等待，必须等 blocker commit/rollback 或手工 kill
- 特别警惕隐式事务：某些 JDBC 驱动或应用框架会在 autocommit=false 下长期 hold 住子表 insert，却不报错
真正难处理的从来不是建索引本身，而是那个没人记得自己开了事务、又忘了 commit 的会话。
