可通过AWR中SQL的PLAN_HASH_VALUE是否稳定来确认SPM基线是否实际生效：若多个快照中该值持续一致，说明基线起作用；若频繁跳变，则基线未生效，需结合V$SQL、DBA_HIST_SQLSTAT等进一步排查。
怎么确认SPM基线是否在AWR中被实际使用
awr本身不记录“某条sql用了哪个基线”，但能间接验证：只要基线生效，对应sql的执行计划就不会跳变，awr报告里的plan_hash_value就会稳定。如果某sql在多个快照里plan_hash_value频繁变化，说明spm没起作用——哪怕dba_sql_plan_baselines里状态是enabled=yes、accepted=yes。
实操建议：
- 查
V$SQL确认该SQL当前实际用的PLAN_HASH_VALUE，再对比AWR报告中“SQL Statistics”页的历史PLAN_HASH_VALUE列，看是否连续几小时一致 - 若发现跳变，立刻查
DBA_HIST_SQLSTAT.PLAN_HASH_VALUE和DBA_HIST_SQLTEXT.SQL_TEXT关联，确认是不是同一条SQL（注意SQL_ID可能因大小写/空格不同而漂移） - RAC环境下必须跨实例查
GV$SQL，因为基线虽全局，但各节点缓存可能未同步；单查V$SQL只反映当前实例情况
为什么AWR报告里看不到SPM相关的等待或统计
SPM本身不产生等待事件，它只是在硬解析阶段干预优化器决策。所以你在AWR的“Top 5 Timed Events”或“Time Model”里永远找不到spm、baseline这类关键词。它的效果体现在下游指标上：比如硬解析时间没降，但db time下降了，或者physical reads显著减少——这说明劣质计划被挡住了。
实操建议：
- 重点对比启用SPM前后的两个AWR报告，关注“SQL Statistics”页的
Elapsed Time Per Exec和Buffer Gets Per Exec变化，而非解析相关指标 - 若启用了
optimizer_capture_sql_plan_baselines=TRUE，AWR中DBA_HIST_SQLSTAT的PARSE_CALLS可能微增（因捕获新计划），但EXECUTIONS应更稳定 - 别依赖ADDM自动提示SPM问题——ADDM不会说“你该用SPM”，它只会说“某SQL执行计划变差”，这时才需要人工回溯基线状态
如何用AWR快照定位SPM失效的具体时间点
SPM失效往往不是突然发生的，而是伴随统计信息更新、对象DDL、或参数变更逐步暴露。AWR快照的时间戳就是你的刻度尺：找出PLAN_HASH_VALUE开始跳变的第一个快照ID，再查该快照前后15分钟内的关键变更。
实操建议：
- 运行
SELECT snap_id, begin_interval_time FROM dba_hist_snapshot WHERE snap_id IN (X, Y) ORDER BY snap_id，确认跳变发生在哪两个快照之间 - 查
DBA_HIST_OPTIMIZER_STATISTICS_HISTORY，看跳变快照附近是否有LAST_ANALYZED更新 - 查
DBA_HIST_PARAMETER，过滤NAME IN ('optimizer_mode', '_optim_peek_user_binds')，确认参数是否在跳变前后被修改 - 特别注意RAC场景：用
GV$SQL查各节点PLAN_HASH_VALUE是否一致，若仅node2跳变，大概率是该节点统计信息未同步或游标未刷新
哪些AWR配置会影响SPM效果的可观测性
默认AWR配置会严重削弱SPM分析能力——快照太稀疏、SQL捕获太少、保留期太短，导致你根本找不到计划跳变的证据链。
实操建议：
-
topnsql至少设为50：否则中等负载SQL被截断，AWR里只剩TOP 30，而真正跳变的SQL可能排第35名 - 快照间隔缩到15分钟：计划跳变常发生在统计信息收集后几分钟内，60分钟快照大概率错过
- 保留期扩到31天：SPM问题常有延迟暴露，比如某基线在周一启用，周四才因并发压力触发劣质计划，没31天保留根本无法回溯
- RAC下必须确认所有实例
optimizer_capture_sql_plan_baselines值一致，否则AWR里看到的基线来源origin字段会混杂AUTO-CAPTURE和MANUAL-LOAD，无法归因
