ash无法直接查看plan_hash_value变化，因其仅记录sql_id、session_state等运行时状态，不存执行计划快照；需先用ash定位cpu或i/o飙升的分钟级窗口，再通过dba_hist_sqlstat对比该时段前后快照中的plan_hash_value及ela_sec_per_exec等指标，才能精准确认执行计划切换及是否劣化。
直接查ASH看不出plan_hash_value变化
ASH里没有plan_hash_value字段，它只存sql_id、event、session_state等运行时状态，不记录执行计划快照。想确认某条SQL是否换了执行计划，不能靠v$active_session_history单表判断——哪怕同一sql_id在ASH里频繁出现不同等待事件，也可能是参数、绑定值或统计信息微调导致的运行时行为差异，不是plan切换本身。
用ASH + AWR组合定位plan切换时间点
核心思路是：先用ASH锁定性能突变发生的具体分钟级窗口，再用AWR快照对比该窗口前后dba_hist_sqlstat里的plan_hash_value是否变动。
- 从
v$active_session_history查出CPU或I/O飙升时段的高频sql_id：SELECT sql_id, COUNT(*) FROM v$active_session_history WHERE session_state = 'ON CPU' AND sample_time > SYSDATE - INTERVAL '10' MINUTE GROUP BY sql_id ORDER BY 2 DESC FETCH FIRST 5 ROWS ONLY - 拿到可疑
sql_id后，查dba_hist_sqlstat中该SQL在突变前后两个相邻快照里的plan_hash_value：SELECT snap_id, plan_hash_value, executions, elapsed_time/NULLIF(executions,0)/1000000 ela_sec_per_exec FROM dba_hist_sqlstat WHERE sql_id = 'your_sql_id' AND snap_id IN (12345, 12346) ORDER BY snap_id - 如果
plan_hash_value不同，且ela_sec_per_exec同步跳升，基本可断定是执行计划劣化引发的性能抖动
为什么不能只看DBA_HIST_SQL_PLAN？
dba_hist_sql_plan只存历史执行计划文本，不带时间戳粒度到秒级的生效时刻。一个sql_id可能有多个plan_hash_value共存于该视图，但你无法知道“新计划从第几个采样点开始实际执行”。真正能锚定“第一帧劣化样本”的，只有ASH的sample_time——它精确到微秒，且和sql_id强绑定。所以必须先用ASH框出时间，再回溯AWR验证。
容易忽略的细节：plan切换未必等于性能下降
同一个sql_id在不同快照里plan_hash_value变了，不代表一定有问题。比如：
- 统计信息自动收集后，优化器选了更优的索引范围扫描，
plan_hash_value变了但响应更快 - 绑定变量窥探（bind peeking）触发了不同子游标，
child_number不同导致plan_hash_value不同，但各子游标都合理 -
dba_hist_sqlstat里executions为0的快照行，说明该计划根本没被执行过，只是被缓存了
关键得交叉看ela_sec_per_exec、buffer_gets、disk_reads这些实际消耗指标是否同步恶化，而不是盯着plan_hash_value数字本身。
