必须用awrddrpt.sql进行时段对比，因其强制对齐快照边界、统一归一化单位并校验dbid/inst_num；而awrrpt.sql报告含格式噪音、快照间隔不一致、起止时间不对齐，直接比对会导致指标失真。
必须用 awrddrpt.sql，不能拿两份 awrrpt.sql 或 awrsqrpt.sql 报告手动比对——90% 的“看不出变化”其实是指标失真，不是没变化。
为什么 awrrpt.sql 报告不能直接对比
你把两份 awrrpt.sql 输出丢进 Excel 或 diff 工具里逐列看，大概率在比噪音：
-
awrrpt.sql输出含大量格式字符（分隔线、空行、页眉）、终端宽度依赖折行，同一参数两次运行内容可能不一致 - 关键指标如 “Logical Reads per Sec” 是按快照间隔归一化计算的，若 baseline 时段快照间隔是 60 分钟、comparison 是 15 分钟，数值单位已不同，直接比等于比 apples 和 oranges
- 没强制对齐快照边界：一个报告起于
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 的正确调用方式
别依赖交互式提示输时间字符串——时区、NLS_DATE_FORMAT、会话时区都可能导致解析错位。直接用快照 ID 最稳：
- 先查准快照：
SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot WHERE begin_interval_time >= TRUNC(SYSDATE)-2 ORDER BY snap_id DESC - 在 SQL*Plus 中定义变量后执行：
DEFINE START_SNAP_ID = 12345 DEFINE END_SNAP_ID = 12365 DEFINE BASELINE_START_SNAP_ID = 12000 DEFINE BASELINE_END_SNAP_ID = 12020 @?/rdbms/admin/awrddrpt
- 交互时按提示依次输入：
TEXT（或HTML），dbid（多租户/恢复库场景不能省），inst_num（RAC 必填），最后是四组snap_id
怎么看懂 awrddrpt.sql 输出里的真实差异
报告不是堆数字，核心是识别“变差了且变化显著”的指标：
- 盯
%Diff列：绝对值 > |20%| 且 绝对变化量足够大（如DB Time增加 1200 秒）才值得深挖；Parse CPU to Parse Elapsed %: -0.3%这类可忽略 - 优先看
DB Time分解：若DB Time+50% 但CPU Time只 +5%，说明瓶颈不在 CPU，大概率是 I/O、锁或网络延迟 - Concurrency 类等待（如
enq: TX - row lock contention）翻倍 ≠ SQL 要调优，更可能是应用事务设计或缺失索引 - AWR 平滑了瞬时尖峰，若怀疑短时高负载，必须补查对应时段的
ASH_REPORT_TEXT，看session_state = 'WAITING'且event出现频次 > 100 次/分钟的事件
真正容易被忽略的是快照时间对齐精度和 startup_time 一致性——哪怕只差 1 分钟或一次隐式重启，整个对比就失去基准。别图省事输时间字符串，老老实实查 dba_hist_snapshot 拿 snap_id。
