必须用awrddrpt.sql生成差异报告，因其强制对齐快照边界、统一归一化单位（如每事务）、标出%Diff和↑↓箭头；手动对比两份awrrpt.sql易因格式噪音、快照间隔不一致、起止时间偏差35秒以上、未校验dbid/inst_num导致指标失真误判。
必须用 awrddrpt.sql 生成差异报告，不能手动比对两份 awrrpt.sql 输出——90% 的“看不出变化”其实是指标失真，不是没变化。
为什么直接 diff 两份 awrrpt.sql 报告会误判
你把两份 awrrpt.sql 丢进文本工具或 Excel 里逐行比，本质上是在比噪音：
-
awrrpt.sql含大量格式字符（分隔线、空行、页眉）、终端宽度依赖折行，同一参数两次运行内容可能不一致 - 关键指标如
Logical Reads per Sec是按快照间隔归一化计算的；若 baseline 时段快照间隔是 60 分钟、comparison 是 15 分钟，数值单位已不同 - 没有强制对齐快照边界：一个报告起于
09:00:12，另一个起于09:00:47，哪怕只差 35 秒，在高波动负载下 AAS 偏差就超 20% - 默认不校验
dbid和inst_num，RAC 下易跨实例误比，多租户下可能混 PDB 数据
运行 awrddrpt.sql 前必须确认的三件事
漏掉任一条件，脚本会报错（如 ORA-13783）或输出结果不可信：
- 查当前连接上下文：
SELECT sys_context('userenv', 'con_name') FROM dual—— 确保已连到目标 PDB；跨 PDB 对比必须先切库再执行 - 确认无实例重启：
SELECT snap_id, startup_time FROM dba_hist_snapshot WHERE snap_id IN (&start_snap_id, &end_snap_id, &baseline_start_snap_id, &baseline_end_snap_id) ORDER BY snap_id—— 所有四组快照的startup_time必须完全一致 - 两个时间段长度建议严格相等（如都是 3600 秒），否则
per second类指标分母不同，Execs per Sec会扭曲；若必须不等长，报告中只重点看per txn或total列
怎么看懂 awrddrpt.sql 输出里的关键差异
对比报告不是堆数字，核心是识别“哪些指标变差了，且变化是否真实显著”：
-
%Diff列值 > |20%| 且绝对值足够大才值得深挖：比如DB Time增加 1200 秒、Physical Reads per Txn+420%，但Parse CPU to Parse Elapsed %: -0.3% 直接忽略 - 重点关注带 ↑↓ 箭头的行：
db file sequential read↑表示单块读响应变慢或访问暴增；library cache: mutex X↑暗示争用加剧 - 别只盯
Top 5 Timed Foreground Events总占比，要下钻看Avg Wait (ms)—— 如果该值翻倍以上，才说明 I/O 或锁响应真变差 - 新 SQL 突然上榜？立刻查它的
SQL_ID和执行计划变更：SELECT * FROM dba_hist_sql_plan WHERE sql_id = '&sql_id' AND plan_hash_value IN (SELECT DISTINCT plan_hash_value FROM dba_hist_sqlstat WHERE sql_id = '&sql_id')
最容易被忽略的是时间粒度对齐和归一化口径。哪怕快照 ID 差一个，或者 Elapsed Time 差几十秒，AAS 和 DB Time per Sec 就可能漂移 30% 以上——这不是性能问题，是测量误差。
