AWR不能直接验证SQL Profile是否生效，因其不记录Profile绑定关系且DISPLAY_AWR的ADVANCED输出中永不显示“SQL Profile used”；需通过DBA_HIST_SQLSTAT中plan_hash_value是否稳定、以及DISPLAY_AWR对比启用前后cardinality预估变化来间接判断。
AWR不能直接验证SQL Profile是否生效——它不记录Profile绑定关系，也不在执行计划Note中写明“SQL Profile used”。想确认Profile起没起作用，得靠间接证据：查DBA_HIST_SQLSTAT里plan_hash_value是否稳定，再用DBMS_XPLAN.DISPLAY_AWR比对启用Profile前后的执行计划结构和cardinality预估变化。
为什么DISPLAY_AWR不显示“SQL Profile used”
Oracle只在V$SQL的sql_profile字段和DBA_SQL_PROFILES里存Profile绑定信息，但AWR快照不捕获该字段。即使Profile已绑定且生效，DBMS_XPLAN.DISPLAY_AWR(..., 'ADVANCED')输出的Note区也**永远不会出现“SQL Profile used”字样**——这和SQL Plan Baseline完全不同，别被误导。
- Profile生效是优化器内部行为，不产生可审计的Note标记
-
DBA_HIST_SQL_PLAN里没有profile_name列，无法关联历史计划与Profile - 唯一能确认Profile参与决策的方式，是看它是否改变了最终生成的执行树或
cardinality预估值
查DBA_HIST_SQLSTAT看plan_hash_value是否收敛
Profile的核心价值是引导优化器选更优路径。如果Profile生效，同一sql_id在多个快照中应表现出更稳定的plan_hash_value；若仍频繁跳变，说明Profile未被采纳，或被其他因素（如统计信息变更、绑定变量窥探）覆盖。
- 运行查询（替换
your_sql_id）：SELECT plan_hash_value, COUNT(*), MIN(sample_time), MAX(sample_time) FROM dba_hist_sqlstat WHERE sql_id = 'your_sql_id' AND sample_time > SYSDATE - 7 GROUP BY plan_hash_value ORDER BY MIN(sample_time);
- 返回多行 → Profile大概率未生效，或仅在部分执行中触发（如绑定变量值导致Plan Stability失效）
- 返回单行 +
plan_hash_value与未启用Profile时不同 → 是Profile生效的强信号 - 注意：
DBA_HIST_SQLSTAT默认只保留最近1000个快照，高频SQL可能被截断
用DISPLAY_AWR对比Cardinality预估偏差
Profile常通过OPT_ESTIMATE等Hint修正优化器对某表/索引/连接的选择性预估。这种修正不会改plan_hash_value，但会显著影响Rows列数值。必须用DISPLAY_AWR带'ADVANCED'参数，才能看到每个操作符的预估行数。
- 查启用Profile前的计划：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('your_sql_id', NULL, &old_snap_id, 'ADVANCED')); - 查启用Profile后的计划：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('your_sql_id', NULL, &new_snap_id, 'ADVANCED')); - 重点对比TABLE ACCESS或JOIN节点的
Rows值：若某节点从预估100行变为预估12000行，且实际执行返回量接近后者，说明Profile的cardinality修正已起效 - 若
Rows列无变化，但Cost下降明显，可能是Profile调整了CPU_COST或IO_COST权重，需结合DBA_SQL_PROFILES中category和status字段确认是否ENABLED=YES
排查Profile未生效的三个硬性条件
Profile存在 ≠ Profile被用。以下任一条件不满足，Profile都会被跳过：
-
DBA_SQL_PROFILES.STATUS≠ 'ENABLED'：状态为DISABLED或IGNORED时，优化器直接忽略 -
optimizer_use_sql_profiles=FALSE：该隐含参数控制全局开关，检查用SELECT value FROM v$parameter WHERE name = 'optimizer_use_sql_profiles'; - SQL文本发生微小变更（如空格增减、注释位置变动）：Profile绑定基于SQL文本哈希，非精确匹配则不触发
Profile的生效逻辑比Baseline更隐蔽，它不留下任何显式痕迹，只能靠执行路径稳定性与预估值变化来反推。最易被忽略的是：Profile一旦绑定，就不再随统计信息自动演进——旧Profile遇上新数据分布，可能反而让计划变得更差。
