ASH不保存执行计划，只记录采样时刻的运行上下文；它仅存储活跃会话的SQL_ID、等待事件、资源消耗等快照信息，不含OPERATION、OBJECT_NAME等计划结构字段，SQL_PLAN_HASH_VALUE仅为哈希标识，无法还原实际执行计划。
ASH 本身不保存执行计划，只记录采样时刻的运行上下文
oracle 的 v$active_session_history（ash）本质是一张内存中滚动采样的快照表，每秒最多捕获一次活跃会话状态。它存的是「谁、在哪个 sql_id、正在做啥操作、等什么事件、消耗多少 cpu/io」，但**不存执行计划结构**——没有 operation、options、object_name 这些字段。你查 v$ash 或 awr 报告里的 ash 摘要部分，看到的只是 sql 执行中的“切片”，不是“路线图”。
常见误解是：既然 ASH 能看到 SQL_ID 和 SQL_PLAN_HASH_VALUE，那应该能还原计划。但注意：SQL_PLAN_HASH_VALUE 只是个哈希值，用于快速比对计划是否相同，它本身不含任何计划节点信息；而且这个值在游标失效、绑定变量变化、统计信息更新后可能复用或变更，不能反向查出具体计划。
想看执行计划，必须用 DBMS_XPLAN.DISPLAY_CURSOR 查 V$SQL_PLAN
真正存执行计划的地方是共享池中的游标元数据，对应动态视图 V$SQL_PLAN。要拿到某次执行的实际计划，得靠 DBMS_XPLAN.DISPLAY_CURSOR，且必须满足两个前提：
- 该 SQL 必须已执行过（不能只
EXPLAIN PLAN FOR），否则V$SQL_PLAN里没记录 - 执行时的
CHILD_NUMBER要准确——尤其在存在大量子游标（VERSION_COUNT > 1）时，错选CHILD_NUMBER会导致显示错误计划（比如用了空绑定值生成的劣质计划） - 如果 SQL 已被老化出共享池，
V$SQL_PLAN就查不到，此时只能依赖 AWR 里保留的历史计划（DBA_HIST_SQL_PLAN），但需确认 AWR 快照间隔和保留策略是否覆盖目标时段
典型命令：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('abc123xyz', 0, 'ALLSTATS LAST'));
其中 'ALLSTATS LAST' 是关键：它把运行时统计（如 STARTS、E-Rows、A-Rows）和计划结构叠在一起，才能看出哪一步卡住了、估算是否严重偏差。
AWR SQL 报告里 Plan Hash Value 相同 ≠ 计划真一致
AWR 报告顶部的 SQL 统计摘要会列出 Plan Hash Value，但它只是个 64 位整数哈希。Oracle 12c+ 引入了自适应计划（Adaptive Plans）和 SQL Plan Directives（SPD），同一个 SQL_ID + 同一个 PLAN_HASH_VALUE，实际执行中可能动态切换分支（比如从 NESTED LOOPS 切到 HASH JOIN）。这种切换不会改变哈希值，但会显著影响性能。
所以，仅靠 AWR 报告里 Plan Hash Value 没变，不能断定执行逻辑没变。要验证是否真用了自适应计划，得查：
-
V$SQL.IS_ADAPTIVE = 'Y'（说明该游标启用自适应） -
DBA_HIST_SQL_PLAN.OTHER_XML字段里是否有<adaptive>true</adaptive>标签 - 用
DBMS_XPLAN.DISPLAY_CURSOR(..., 'ADAPTIVE')显式展开自适应部分
漏掉这点，就容易误判“计划没变，为啥突然慢了？”——其实是计划内部悄悄换了路。
绑定变量窥探（Bind Peeking）导致 ASH 看到的 SQL_ID 对应多个隐性计划
当 SQL 使用绑定变量，且首次硬解析时传入的值有倾斜（比如 :dept_id = 10 返回 10 行，而 :dept_id = 50 返回 10 万行），优化器会基于第一次窥探到的值生成计划，并缓存为默认子游标。后续即使传入不同值，只要没触发重优化（如 SPD 生效、统计信息变化），仍复用该计划。
这时 ASH 里所有这些调用都显示同一个 SQL_ID，但背后可能是完全不同的执行路径。你看到的 SQL_PLAN_HASH_VALUE 可能始终不变，可实际走的是全表扫描还是索引扫描，取决于绑定值分布。
排查方法：
- 查
V$SQL_SHARED_CURSOR中BIND_MISMATCH = 'Y'的记录，确认是否存在因绑定值差异导致的游标分裂 - 用
SELECT * FROM V$SQL_BIND_CAPTURE WHERE SQL_ID = 'xxx'看历史捕获的绑定值样本，对比是否覆盖了高基数/低基数场景 - 对关键 SQL，考虑用
OPTIMIZER_USE_SQL_PLAN_BASELINES = TRUE锁定稳定计划，或改用/*+ OPT_PARAM('_optim_peek_user_binds' 'FALSE') */关闭窥探（慎用）
最易被忽略的一点：ASH 不记录绑定变量值本身，所以你永远无法仅从 ASH 推断某次采样到底是哪个绑定值触发的劣质路径——必须结合 V$SQL_BIND_CAPTURE 和业务日志交叉定位。
