AWR查不到历史执行计划是因为SQL未满足采样条件——仅捕获V$SQL中活跃且EXECUTIONS_DELTA>0或ELAPSED_TIME_DELTA显著的语句；需先确认快照存在、SQL是否被捕获，再手动触发快照提高捕获概率。
AWR 里查不到历史执行计划，大概率不是脚本或权限问题，而是数据根本没被采样进去——AWR 不是全量记录，它只捕获“当时在 V$SQL 中且满足活跃阈值”的语句。
查不到计划前先确认 SQL 是否进了 AWR
AWR 快照默认每小时一次，且只保存 EXECUTIONS_DELTA > 0 或 ELAPSED_TIME_DELTA 显著的 SQL。刚跑完就查 DBA_HIST_SQLTEXT，基本为空。
- 先查快照是否存在：
SELECT MAX(SNAP_ID), MAX(BEGIN_INTERVAL_TIME) FROM DBA_HIST_SNAPSHOT - 再查目标 SQL 是否被捕获：
SELECT SQL_ID, SQL_TEXT FROM DBA_HIST_SQLTEXT WHERE SQL_TEXT LIKE '%关键字段%'（别依赖SQL_ID精确匹配，空格/换行不同就会生成新 ID） - 如果业务允许，手动触发快照：
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT，再立即执行目标 SQL，提高捕获概率
用 DBMS_XPLAN.DISPLAY_AWR 提取计划时的硬限制
这个函数能回溯，但前提是 SQL_ID 准确、计划真实存在过、且你有访问 DBA_HIST_SQL_PLAN 的权限。
-
SQL_ID大小写敏感，复制时容易带入零宽空格（\u200b），粘贴后报no rows selected很可能就是这个原因 - 第二、三参数留空表示查全部快照，但输出极长；建议先用
DBA_HIST_SQLSTAT锁定具体快照范围：SELECT SNAP_ID, PLAN_HASH_VALUE FROM DBA_HIST_SQLSTAT WHERE SQL_ID = 'xxx' AND SNAP_ID BETWEEN 12345 AND 12346 - 执行：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('abc123xyz', 12345, 12346, 'TYPICAL'))，'TYPICAL'比'ALL'更清晰，过滤掉冗余统计字段
为什么 PLAN_HASH_VALUE 相同，性能却差很多
PLAN_HASH_VALUE 只校验执行树结构，不反映谓词推入位置、绑定变量窥探结果、临时表物化时机等细节。尤其在 RAC 环境下，两个节点计划看起来一样，但一个节点大量等待 gc cr multi block request，IO 开销已翻倍。
- 单看
DISPLAY_AWR输出不够，必须结合DBA_HIST_ACTIVE_SESS_HISTORY查等待事件分布 - 如果发现
db file sequential read高企，再查DBA_HIST_SEG_STAT确认是不是某张表被反复全扫——那说明执行计划虽未变，但索引实际失效或统计信息严重偏差 -
DBA_HIST_SQL_PLAN中的OTHER_XML字段含谓词信息，可用EXTRACTVALUE解析，但 10.2.0.5 以下版本该字段不存在，会报ORA-00904: "OTHER_XML" invalid identifier
替代方案：当 AWR 空白时怎么捞计划
如果 DBA_HIST_SQLTEXT 和 DBA_HIST_SQL_PLAN 都查不到，说明该 SQL 未被 AWR 捕获，此时只能退到内存级视图，但仅限它还没从共享池老化。
- 用
V$SQL_FULLTEXT查完整 SQL 文本（V$SQL.SQL_TEXT只返回前 1000 字符）：SELECT DBMS_LOB.SUBSTR(SQL_FULLTEXT, 4000, 1) FROM V$SQL_FULLTEXT WHERE SQL_ID = 'xxx' - 用
DBMS_XPLAN.DISPLAY_CURSOR查当前缓存计划：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('xxx', NULL, 'ALLSTATS LAST'))，'ALLSTATS LAST'显示上一次执行的真实 I/O 和时间消耗 - 注意
V$SQL中同一SQL_ID可能对应多个CHILD_NUMBER（尤其 11g 启用 ACS 时），必须结合V$SQL_SHARED_CURSOR确认哪个子游标真正执行了高负载操作
AWR 不是黑匣子，它只保存“被看见”的计划；查不到时，优先怀疑时间窗口、采样条件和 SQL_ID 来源是否可靠，而不是工具本身失效。
