执行计划变差后不能直接改统计信息，因收集耗时长、硬解析不及时（no_invalidate默认AUTO_INVALIDATE导致延迟5小时），且问题可能根本与统计信息无关（如11g中SQL Plan Baseline未验证即启用引发漂移）；AWR仅存plan_hash_value和SQL文本，需用DBMS_SPM.LOAD_PLANS_FROM_AWR（11.2.0.2+支持）从dba_hist_sql_plan等视图导入历史好计划，但要求该计划曾被AWR采样，且导入后需确保optimizer_use_sql_plan_baselines=TRUE、SQL文本完全一致、未加NO_SQL_PLAN_BASELINE提示。
执行计划变差后，为什么不能直接改统计信息？
因为收集统计信息耗时长、触发硬解析不及时，且可能根本不是统计信息导致的。比如 optimizer_adaptive_features 在 19c 后启用（11g 不涉及），但 11g 中 optimizer_capture_sql_plan_baselines 开启后，新计划若未验证就自动启用，也可能造成“漂移”。更关键的是：一旦计划变差，业务已卡顿，你没时间等 dbms_stats.gather_table_stats 跑完，尤其对大表。
怎么从 AWR 中捞出历史好计划并导入 SPM？
AWR 本身不存完整执行计划，但存 plan_hash_value 和 SQL 文本；真正能导出可复用计划的，是 AWR 快照里关联的 DBA_HIST_SQL_PLAN + DBA_HIST_SQLSTAT。你需要用 DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE 或更稳妥的 DBMS_SPM.LOAD_PLANS_FROM_AWR —— 但注意：后者在 11.2.0.2+ 才支持，且要求目标 SQL 在 AWR 快照周期内确实被采样过。
- 先查出 SQL 的
sql_id：SELECT sql_id, sql_text FROM v$sql WHERE sql_text LIKE '%your_condition%'; - 确认该
sql_id在 AWR 中有历史计划：SELECT DISTINCT plan_hash_value FROM dba_hist_sql_plan WHERE sql_id = 'xxx'; - 用
DBMS_SPM.LOAD_PLANS_FROM_AWR导入指定plan_hash_value：BEGIN DBMS_SPM.LOAD_PLANS_FROM_AWR( begin_snap => 12345, end_snap => 12346, basic_filter => 'sql_id = ''abc123'' AND plan_hash_value = 1234567890' ); END;
导入后计划没生效？检查这几个硬条件
SPM 生效不是“导入即用”，它受优化器开关和绑定变量影响。常见失效原因：
-
optimizer_use_sql_plan_baselines参数必须为TRUE（默认是 TRUE，但有些客户会关） - SQL 文本必须完全一致 —— 尾部空格、换行、大小写差异都会导致匹配失败
- 如果用了绑定变量，而历史计划是在不同绑定值下生成的，
force_matching模式未开启时，SPM 可能不匹配 - 执行时若加了
/*+ NO_SQL_PLAN_BASELINE */提示，会绕过基线
coe_load_sql_profile.sql 和 SPM 基线的区别在哪？
coe_load_sql_profile.sql 本质是创建 SQL Profile（基于 HINT 注入），它优先级高于 SPM 基线，但属于“补丁式”修复：Profile 是会话级或语句级的 hint 封装，不参与计划演化；而 SPM 基线是存储在 sys.sqlobj$ 等对象中的正式计划控制机制，支持自动验证、演进和禁用。生产环境建议优先走 SPM，Profile 仅用于紧急兜底或跨版本迁移场景。
真正容易被忽略的点是：AWR 快照间隔默认 60 分钟，如果好计划只在某次短时负载中出现过，但没被采样到 AWR，那 LOAD_PLANS_FROM_AWR 就查不到——此时只能从 v$sql_plan 或 cursor cache 里抓，或者靠之前手动捕获的 baseline。
