awr无法记录死锁瞬间的互锁关系，但能识别高风险锁竞争模式：如enq: tx - row lock contention在top 5事件中占比超5%且平均等待>10ms、同一sql_id执行计划频繁变化、特定表长期高逻辑读且存在无索引update或for update操作。
AWR里查不到死锁本身，但能发现高风险模式
AWR不记录死锁发生瞬间的互锁关系，它只保存聚合后的等待统计。死锁被Oracle自动回滚后，ORA-00060只会写进alert.log和trace文件，AWR里看不到“谁卡住谁”。但它能暴露持续存在的锁竞争隐患——比如某SQL长期、高频地触发enq: TX - row lock contention，这就是死锁温床。
关键不是等死锁发生，而是提前识别这类SQL：
-
enq: TX - row lock contention在AWR报告“Top 5 Timed Foreground Events”中占比超过5%，且Avg Wait Time> 10ms，说明行锁争抢已成常态 - 同一
sql_id在多个快照中反复出现在“SQL ordered by Gets”和“SQL ordered by Reads”前列，但执行计划不稳定（plan_hash_value频繁变化），暗示并发更新逻辑混乱 - “Segments by Logical Reads”里某张表长期霸榜，且该表上存在大量
FOR UPDATE或UPDATE ... WHERE无索引谓词的操作
从AWR报告里定位高危SQL的实操路径
直接翻AWR报告PDF容易漏细节，建议用SQL查原始数据：
先确认时间范围是否有异常等待：
SELECT snap_id, begin_interval_time, end_interval_time
FROM dba_hist_snapshot
WHERE begin_interval_time BETWEEN TO_DATE('2026-07-27 13:44', 'yyyy-mm-dd hh24:mi')
AND TO_DATE('2026-07-27 13:46', 'yyyy-mm-dd hh24:mi');
再查该时段内TX锁事件TOP SQL：
SELECT sql_id, COUNT(*) waits, SUM(time_waited)/1000 total_sec
FROM dba_hist_active_sess_history
WHERE event = 'enq: TX - row lock contention'
AND sample_time BETWEEN TO_DATE('2026-07-27 13:44', 'yyyy-mm-dd hh24:mi')
AND TO_DATE('2026-07-27 13:46', 'yyyy-mm-dd hh24:mi')
GROUP BY sql_id
ORDER BY total_sec DESC;
拿到sql_id后，查它的执行计划和对象访问路径：
SELECT plan_hash_value, object_name, operation, options
FROM dba_hist_sql_plan
WHERE sql_id = '&your_sql_id'
AND snap_id IN (
SELECT snap_id FROM dba_hist_snapshot
WHERE begin_interval_time BETWEEN TO_DATE('2026-07-27 13:44', 'yyyy-mm-dd hh24:mi')
AND TO_DATE('2026-07-27 13:46', 'yyyy-mm-dd hh24:mi')
)
ORDER BY id;
重点看是否出现全表扫描+FOR UPDATE，或对同一张表的多个UPDATE语句使用不同索引/顺序访问。
为什么只看AWR不够？必须搭配ASH补全链条
AWR把1分钟内的采样合并成一条记录，而死锁往往在几秒内爆发又消失。如果只依赖AWR，你会看到“enq: TX - row lock contention共发生127次”，但完全不知道是1个会话堵了127秒，还是127个会话各堵1秒——后者才是死锁高发场景。
必须用v$active_session_history还原秒级现场：
- 过滤条件要严格：
sample_time > SYSDATE - 1/1440（最近1分钟），event = 'enq: TX - row lock contention'，且blocking_session IS NOT NULL - 重点检查
p1和p2：若两个会话的p1/p2值交叉相等（A.p1 = B.p2 且 A.p2 = B.p1），基本可断定TX锁互持 -
sql_id相同但current_obj#不同，说明它们在更新同一业务逻辑下的不同行——这是典型死锁构造条件
AWR给趋势，ASH给快照；一个告诉你“哪里热”，一个告诉你“谁和谁在掐架”。缺一不可。
容易被忽略的配置陷阱
很多人查不到死锁线索，不是SQL写错，而是底层配置没开：
-
STATISTICS_LEVEL必须设为TYPICAL或ALL，BASIC模式下ASH和AWR数据严重缺失 -
_ash_enable隐含参数被设为FALSE（某些老版本或手动调优后），会导致v$active_session_history为空 - AWR快照间隔大于15分钟，而死锁窗口常短于30秒——快照根本抓不住，需确认
DBA_HIST_SNAPSHOT里interval_minutes是否≤10 - 数据库未启用
deadlock_graph_trace（19c默认开启），导致trace文件不包含完整锁图，只能靠ASH人工拼接
真正难的不是写SQL，是确保这些信号通道全开着。等出问题再查，往往已经覆盖掉了关键采样。
