AWR本身不能还原死锁过程，因其快照间隔60分钟远大于死锁持续时间（常小于1秒），无法捕获瞬时互锁；必须结合ASH每秒采样数据定位“黄金5分钟”内互指会话及精确时间锚点，再用DBA_HIST_ACTIVE_SESS_HISTORY归因。
awr 本身没有“回退”功能，不能还原或重放死锁过程；你真正需要的是用 awr 快照 + ash 数据交叉定位死锁发生的时间窗口和会话链路。
为什么直接查 AWR 报告找不到死锁细节
AWR 快照默认每 60 分钟采集一次，而 Oracle 死锁通常在
-
DBA_HIST_ACTIVE_SESS_HISTORY中的采样点大概率错过死锁发生的精确秒级时刻（比如死锁发生在 14:22:37，但最近入库的样本是 14:22:30 和 14:22:40） -
blocking_session字段在历史表中不稳定：19c 以前版本常为空或为 0；死锁结束后该值会被清空，只剩“单边等待”快照 - AWR 报告里的 “Top Enqueue Waits” 只显示汇总统计（如
enq: TX - row lock contention总等待次数），不带会话 ID、SQL_ID 或阻塞关系
必须先用 V$ACTIVE_SESSION_HISTORY 锁定“黄金 5 分钟”
死锁发生后，V$ACTIVE_SESSION_HISTORY 内存视图仍保留最近 5 分钟（默认）的秒级采样，这是唯一能抓到互指阻塞链的实时入口。执行以下查询（替换时间范围）：
SELECT sample_time, session_id, blocking_session, blocking_session_serial#, event, sql_id, current_obj#
FROM v$active_session_history
WHERE sample_time BETWEEN TIMESTAMP '2026-06-23 14:20:00' AND TIMESTAMP '2026-06-23 14:25:00'
AND event LIKE 'enq: TX%'
AND (blocking_session IS NOT NULL
OR session_id IN (
SELECT blocking_session
FROM v$active_session_history
WHERE sample_time BETWEEN TIMESTAMP '2026-06-23 14:20:00' AND TIMESTAMP '2026-06-23 14:25:00'
AND blocking_session IS NOT NULL
))
ORDER BY sample_time DESC;关键动作：
- 看到两个会话 A 和 B 在**同一
sample_time下互相指向对方的blocking_session→ 实锤死锁链 - 确认
event是enq: TX - row lock contention，不是enq: TX - allocate ITL entry（后者是 ITL 不足，非死锁） - 记下这对会话的
session_id和精确到秒的sample_time，这是后续查历史表的唯一可靠锚点
用 DBA_HIST_ACTIVE_SESS_HISTORY 做归因，不是找现场
拿到精确时间点后，再查历史表验证影响范围和上下文。注意必须加两个硬条件：
- 时间范围严格限定在刚才锁定的 ±10 秒内（例如
sample_time BETWEEN TIMESTAMP '2026-06-23 14:22:35' AND TIMESTAMP '2026-06-23 14:22:45'） - 必须带上
session_id IN (A, B)过滤，避免被其他并发会话干扰 - 重点看
sql_id、current_obj#、p1text/p2text（可关联v$sql和dba_objects查具体 SQL 和对象名）
示例：
SELECT sample_time, session_id, sql_id, current_obj#, p1text, p2text FROM dba_hist_active_sess_history WHERE sample_time BETWEEN TIMESTAMP '2026-06-23 14:22:35' AND TIMESTAMP '2026-06-23 14:22:45' AND session_id IN (123, 456);
结合 AWR 报告看全局负载与 ADDM 建议
有了会话和时间锚点，再生成对应时间段的 AWR 报告（起始时间至少提前 15 分钟，结束延后 15 分钟），重点关注：
- “Top 5 Timed Events” 旁嵌入的
ADDM Findings折叠块 —— 不是最后的独立章节，容易忽略 - “SQL Statistics” 页按
Executions或Elapsed Time排序，找到对应sql_id后点进详情，拿plan_hash_value查执行计划 - “Instance Efficiency Percentages” 中的
Non-Parse CPU Usage %和Parse CPU to Parse Elapsed %，判断是否因硬解析拖慢事务提交
ASH 是视频帧，AWR 是照片；单看照片不知道谁在动，单看视频难判断整体负载。二者必须对齐时间戳才能闭环。
