Oracle 12c如何使用AWR分析SQL性能下降

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，它们反映单次执行的真实开销。

常见陷阱：

1. 忽略EXECUTIONS = 0但CPU_TIME_SEC > 0的SQL（游标异常终止或统计未刷新，数据不可信）
2. 拿问题时段报告直接和“昨天此时”对比，却没确认两个快照间隔是否一致（比如一个30分钟，一个45分钟，比出来全是假象）
3. 在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：

1. CPU per Exec > 10秒，且Executions per Sec ≥ 0.1（说明它每秒都在稳定吃CPU）
2. Elapsed per Exec突增3倍以上，且DB CPU占比同步升高（大概率执行计划劣化）
3. Physical Reads per Exec > 100,000（I/O爆炸，先查索引缺失或统计信息陈旧）

别被SQL ordered by Gets带偏——逻辑读高可能是缓存好，不是问题；真正要盯的是SQL ordered by Disk Reads。

怎么验证是不是执行计划变了

拿到可疑SQL_ID后，用DBMS_XPLAN.DISPLAY_AWR('', NULL, 'ALLSTATS LAST')查它在问题时段的实际执行计划。重点对比三个地方：

1. 是否出现TABLE ACCESS FULL替代了原来的INDEX RANGE SCAN
2. 连接方式是否从HASH JOIN退化为NESTED LOOPS，且内表驱动行数暴增
3. Predicate Information里是否有FILTER代替ACCESS（意味着没走索引，靠CPU硬过滤）

如果发现变化，再查dba_tab_statistics确认对应表的LAST_ANALYZED时间——统计信息过期是Plan退化的头号原因。

为什么绑定了执行计划还是没生效

SQL Plan Management（SPM）绑定失败，常见于多用户共用同一SQL文本但对象不一致的场景。比如：

1. 两个用户P1BEMADM和P1FEMADM都执行SQL_ID fr0nhywcycrsa，但各自schema下同名索引列顺序不同、或索引名不一致
2. 绑定时指定访问A1_IDX，但另一个用户下该索引不存在或结构不匹配
3. 表数据量差异巨大（一个用户表只有100行，另一个有1亿行），导致优化器拒绝复用同一Plan

此时DBA_SQL_PLAN_BASELINES里能看到Baseline状态是UNACCEPTED或FIXED = NO，得用DBMS_SPM.ALTER_SQL_PLAN_BASELINE强制启用并设为FIXED，但必须先确认所有用户下对象定义完全一致。

AWR本身不解决执行计划问题，它只告诉你“哪里坏了”。真正修复依赖统计信息刷新、索引补全、绑定变量使用，以及对多schema部署场景的Plan兼容性校验——这些步骤漏掉任何一环，AWR再准也白搭。