awr报告top 10 foreground events不显示sql是设计使然，它按等待事件聚合数据库时间消耗，与sql执行属不同维度；sql关联需通过“sql ordered by elapsed time”等章节及ash analytics交叉分析。
awr报告里的top 10 foreground events本身就不显示sql，这是设计使然，不是漏了、没采集或配置错误。
Top 10等待事件和SQL属于不同维度的数据
Top 10 Foreground Events统计的是“数据库时间被哪些等待类型吃掉了”，它按等待事件（如db file sequential read、log file sync）聚合，不绑定具体SQL语句。SQL执行过程可能触发多种等待，而一个等待事件也可能被成百上千条SQL共同贡献。
所以你看到enq: TX - row lock contention占21.6% DB Time，但报告里不会直接列出“哪条SQL在等”，它只告诉你“行锁争用”是瓶颈类型。
- 真正关联SQL的地方是“SQL ordered by Elapsed Time”“SQL ordered by CPU Time”和“SQL ordered by Gets”三个独立章节
- 如果某条SQL的Elapsed Time远高于CPU+IO耗时之和（比如总耗时90秒，CPU+IO加起来才2秒），那它大概率卡在Top 10里的某个等待上
- 这时要人工交叉比对：看Top 10里哪个事件的总耗时≈该SQL的“Non-Idle Wait Time”，再结合SQL文本判断是否合理
为什么不能把SQL直接塞进Top 10表格里
技术上可行，但会严重破坏可读性与诊断逻辑：
- 一条高并发的
UPDATE可能触发数万次enq: TX - row lock contention，但背后可能是50条不同SQL共享同一主键更新逻辑 - AWR快照粒度是分钟级，而SQL执行是毫秒/秒级，强行绑定会导致采样失真（例如某SQL只在快照开始后3秒执行并卡住，它可能根本没被采到ASH，更不会出现在Top 10归因中）
- Oracle选择解耦：Top 10定位“什么资源卡住了”，SQL章节定位“谁在用这个资源”，ASH则提供会话级时空切片
想快速锁定问题SQL，别盯Top 10表格本身
直接跳转到报告里这三个位置：
-
Segments by Row Lock Waits：如果Top 10里有
enq: TX - row lock contention，这里会列出被争用的表（如WAREHOUSES），缩小范围 -
SQL ordered by Elapsed Time：找SQL文本含
UPDATE WAREHOUSES或DELETE FROM WAREHOUSES的条目，再核对其“Wait Time”列数值 -
ASH Analytics（如果有）：在19c AWR HTML报告里点“ASH Analytics”页签，筛选
EVENT = 'enq: TX - row lock contention'，直接看到CURRENT_OBJ#、CURRENT_FILE#、CURRENT_BLOCK#，甚至能拼出ROWID
真正容易被忽略的是：Top 10里占比低的等待事件，可能恰恰对应单条SQL的致命瓶颈。比如gc buffer busy acquire只占1.2%，但平均等待15ms且由3个会话持续触发——这种信号藏在“平均等待时间”和“等待次数”的组合里，而不是百分比数字本身。
