awr报告中判断sql性能是否真下降，不能只比总cpu time或elapsed time，而应重点看cpu per exec和elapsed per exec；需警惕executions=0但cpu_time_sec>0的异常数据，并确保对比时段快照间隔一致，rac环境须生成全局awr。
怎么看AWR报告里SQL性能是否真下降了
不能只比“CPU Time”或“Elapsed Time”总值——同一SQL在不同时间段执行次数可能差几倍，总耗时高未必代表单次变慢。关键看两个指标：CPU per Exec和Elapsed per Exec，它们反映单次执行的真实开销。
常见陷阱：
- 忽略
EXECUTIONS = 0但CPU_TIME_SEC > 0的SQL（游标异常终止或统计未刷新，数据不可信） - 拿问题时段报告直接和“昨天此时”对比，却没确认两个快照间隔是否一致（比如一个30分钟，一个45分钟，比出来全是假象）
- 在RAC环境只生成单实例AWR，漏掉跨节点争用（如
gc buffer busy、enq: TX - row lock contention）
怎么快速定位是哪条SQL拖垮了系统
打开AWR报告后，直奔SQL Statistics → SQL ordered by CPU Time和SQL ordered by Elapsed Time两页。优先筛出满足以下任一条件的SQL：
-
CPU per Exec> 10秒，且Executions per Sec≥ 0.1（说明它每秒都在稳定吃CPU） -
Elapsed per Exec突增3倍以上，且DB CPU占比同步升高（大概率执行计划劣化） -
Physical Reads per Exec> 100,000（I/O爆炸，先查索引缺失或统计信息陈旧）
别被SQL ordered by Gets带偏——逻辑读高可能是缓存好，不是问题；真正要盯的是SQL ordered by Disk Reads。
怎么验证是不是执行计划变了
拿到可疑SQL_ID后，用DBMS_XPLAN.DISPLAY_AWR('<sql_id>', NULL, 'ALLSTATS LAST')</sql_id>查它在问题时段的实际执行计划。重点对比三个地方：
- 是否出现
TABLE ACCESS FULL替代了原来的INDEX RANGE SCAN - 连接方式是否从
HASH JOIN退化为NESTED LOOPS，且内表驱动行数暴增 -
Predicate Information里是否有FILTER代替ACCESS（意味着没走索引，靠CPU硬过滤）
如果发现变化，再查dba_tab_statistics确认对应表的LAST_ANALYZED时间——统计信息过期是Plan退化的头号原因。
为什么绑定了执行计划还是没生效
SQL Plan Management（SPM）绑定失败，常见于多用户共用同一SQL文本但对象不一致的场景。比如：
- 两个用户
P1BEMADM和P1FEMADM都执行SQL_ID fr0nhywcycrsa，但各自schema下同名索引列顺序不同、或索引名不一致 - 绑定时指定访问
A1_IDX，但另一个用户下该索引不存在或结构不匹配 - 表数据量差异巨大（一个用户表只有100行，另一个有1亿行），导致优化器拒绝复用同一Plan
此时DBA_SQL_PLAN_BASELINES里能看到Baseline状态是UNACCEPTED或FIXED = NO，得用DBMS_SPM.ALTER_SQL_PLAN_BASELINE强制启用并设为FIXED，但必须先确认所有用户下对象定义完全一致。
AWR本身不解决执行计划问题，它只告诉你“哪里坏了”。真正修复依赖统计信息刷新、索引补全、绑定变量使用，以及对多schema部署场景的Plan兼容性校验——这些步骤漏掉任何一环，AWR再准也白搭。
