直接查v$active_session_history才能定位秒级卡顿点，因其采样精度达秒级，可发现AWR报告中因60分钟快照间隔而遗漏的几秒级性能问题。
直接查 v$active_session_history 才能定位秒级卡顿点
AWR 报告里的“ASH 数据链接”是聚合后的摘要，快照间隔默认 60 分钟，而真实卡顿可能只持续几秒——比如一条 SQL 在 15:23:41–15:23:44 这 3 秒内反复被采样到 session_state = 'ON CPU' 且 event 为空，说明它正密集做 JSON 解析或 PL/SQL 循环，但在 AWR 里根本排不进 Top SQL。
必须绕过报告，直查内存视图：v$active_session_history（RAC 环境用 gv$active_session_history）；时间窗口要窄，否则噪声盖过信号：
-
SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE是安全起点，太长（如 30 分钟）容易混入无关会话 - 加
SESSION_ID = <目标SID>和SESSION_SERIAL# = <目标SERIAL#>锁定会话，避免跨会话干扰 - 用
TO_CHAR(SAMPLE_TIME, 'HH24:MI:SS')对齐秒级，观察是否连续多个样本落在同一sql_id+event组合上 - 若
sql_id为空，别急着放弃——看program、module和event，可能是递归调用或硬解析风暴
用 AWR 报告确认该会话的 DB Time 消耗是否异常
ASH 告诉你“卡在哪一秒”，AWR 告诉你“这一秒在整个时间段里占多大比重”。打开问题时段的 AWR 报告，翻到 “Top Sessions by DB Time” 页面，找目标 SESSION_ID：
- 如果它的 DB Time 占比远高于其他会话（比如 40% vs 其他都
- 点进该会话的详情链接（如果有），看它关联的 Top SQL —— 注意不是按 Elapsed Time 排，而是按 DB Time 贡献排序
- 若该会话没有明显 Top SQL，重点查 “Background Processes” 或 “Other” 分类，可能是日志写、归档或递归空间管理操作
- 对比正常时段 AWR 报告中同一
SESSION_ID的 DB Time 占比，确认是否真异常（有些批处理会话本就该高）
交叉验证：从 ASH 找出 sql_id，再回 AWR 查执行计划细节
在 v$active_session_history 中锁定卡顿期间高频出现的 sql_id 后，不能只看它“慢”，得知道“为什么慢”。AWR 不直接显示执行计划，但提供关键线索：
- 在 AWR 报告 “SQL Statistics” 表中找到该
sql_id，记下它的Plan Hash Value - 用
DBMS_XPLAN.DISPLAY_AWR('<sql_id>', NULL, NULL, 'ALL')</sql_id>提取完整计划（注意：需有SELECT_CATALOG_ROLE权限） - 重点检查：是否存在
JSON EVALUATION STEP（说明没走函数索引）、TABLE ACCESS FULL配合高CPU_TIME_PER_EXEC、或INDEX RANGE SCAN但STARTS异常高（可能谓词未下推） - 若 AWR 里查不到该
sql_id，说明它执行次数太少或已老化出共享池——此时要结合v$sql或实时v$session确认是否刚执行完就被刷出
别忽略 blocking_session 和 event 的组合含义
卡顿不一定是自己慢，更可能是被别人堵住。ASH 中 blocking_session 字段和 event 必须一起读：
-
event = 'enq: TX - row lock contention'+blocking_session非空 → 直接查那个 SID 正在执行什么（v$session+v$sql），大概率是未提交事务锁了某行 -
event = 'library cache lock'+blocking_session指向一个长时间运行的 DDL → 说明目标会话卡在等待对象定义变更完成 -
event = 'cursor: pin S wait on X'且blocking_session指向一个频繁硬解析的会话 → 可能是 shared pool latch 争用，需检查v$librarycache的 reloads - 注意
blocking_session本身也可能被更上层会话阻塞，需递归追踪（最多 3 层足够，再深大概率是死锁已被 Oracle 自动杀掉）
真正难的不是查到卡在哪，而是判断那个“卡”是果还是因——比如看到大量 db file sequential read，得先确认是索引设计问题，还是统计信息陈旧导致走了错误路径，这需要把 ASH 的秒级证据和 AWR 的宏观趋势叠在一起看。
