必须用awrddrpt生成Compare Period Report，手动比对两份awrrpt报告必然出错：快照不对齐导致AAS等指标归一化失真、RAC下inst_num未指定掩盖跨节点争用、DBID混淆引发环境混比。
直接用 awrddrpt 生成 compare period report，别手动拉两份 awrrpt 报告再比——快照不对齐、实例范围错位、dbid混淆会让所有对比结果失效。
为什么手动对比两份 awrrpt 报告必然出错
AWR 报告里的关键指标（如 Avg Active Sessions、Physical Reads Per Sec）全是按快照间隔归一化算出来的。两个报告哪怕起始时间差 30 秒，在高波动负载下，AAS 偏差就可能超 20%；RAC 环境下不指定 inst_num，默认只取当前连接实例，跨节点争用直接被掩盖。
常见错误现象包括：
- 用
@?/rdbms/admin/awrrpt分别生成两份报告，再 Excel 对列——Logical Reads看似涨了 40%，实际是问题时段快照间隔为 15 分钟，基线时段为 60 分钟，单位已不一致 - 对比时没确认
dbid，在共享 DBID 的测试库上把旧环境快照和新环境快照混比 - 报告里看到
enq: TX - row lock contention次数翻倍，但 baseline 时段恰有大批量归档日志切换，该等待本就偏高
awrddrpt 必须传的四个参数
awrddrpt 不是“选填参数”的交互式脚本，漏掉任意一个关键参数等于白跑。它底层调用 DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_TEXT，强依赖时间窗口与实例上下文。
必须显式指定：
-
dbid：尤其在多租户或恢复库场景，不能依赖默认值 -
inst_num：RAC 下必须明确，不填 = 只取当前连接实例 -
start_snap_id和end_snap_id：推荐用 snap_id 而非num_days，彻底规避时区、NLS_DATE_FORMAT、会话时区不一致导致的时间解析错位 -
report_type：必须为TEXT或HTML，不支持XML输出
示例（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
执行前务必查 dba_hist_snapshot 确认这四组 snap_id 全部存在且属于同一 dbid+inst_num。
维护窗口对比要盯住的三个硬指标
Compare Period Report 里真正反映系统压力差异的不是总量，而是单位时间强度与资源调度健康度：
-
Avg Active Sessions (AAS)：> CPU 核数即存在排队；若维护窗口 AAS 比基线高 3 倍但DB CPU占比未同步升高，大概率是大量会话卡在 I/O 或锁上，而非真实计算压力 -
DB CPU Per Sec：排除 I/O 等等待后纯计算压力，12c 下注意检查cursor_sharing是否设为force（similar有 bug），否则硬解析飙升会虚抬 CPU -
Buffer Hit %和Buffer Nowait %：低于 95% / 99% 就得动手；若两者同步下跌且latch: cache buffers chains等待上升，说明热点块争用已从磁盘转移到 buffer cache，加db_cache_size可能无效
最易被忽略的是快照粒度本身——12c 默认 60 分钟快照，但维护窗口常含短时尖峰（如 RMAN 备份、统计信息收集）。如果对比窗口内恰好夹着一次 5 分钟的 gather_stats_job，latch: shared pool 和 parse count (hard) 会异常跳升，但这不代表业务 SQL 有问题，得结合 DBA_HIST_ACTIVE_SESS_HISTORY 下钻秒级确认是否真由用户会话触发。
