应使用awrddrpt生成compare period report而非手动对比两份awrrpt，因高峰与低峰快照必须长度相等、边界对齐且无实例重启，需通过快照id精确指定并验证startup_time一致，避开自动任务干扰，且必须显式传入dbid和inst_num以确保rac或多租户环境准确性。
直接用 awrddrpt 生成 Compare Period Report，别手动比两份 awrrpt ——高峰和低峰时段快照不对齐、归一化单位不一致，手动对比的“差异”90%是噪音，不是真实性能变化。
怎么选对高峰和低峰的快照ID
高峰和低峰必须是“长度相等、边界对齐、无重启”的连续快照段。比如都选 30 分钟，起始快照 ID 必须严格对应采集起点（不是“大概10:00”这种模糊时间）。
- 先查准快照：运行
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，人工挑出业务监控确认的高峰起止时刻最近的快照ID - 验证实例连续性：执行
SELECT snap_id, startup_time FROM dba_hist_snapshot WHERE snap_id IN (&peak_start, &peak_end, &low_start, &low_end)，所有四条记录的startup_time必须完全一致 —— 有任意一个不同，说明期间实例重启过，整段对比失效 - 避开自动任务干扰：高峰别选在统计信息自动收集（
auto optimizer stats collection）或备份窗口内；低峰也别选在凌晨DBMS_SCHEDULER批处理刚结束的那几分钟，ASH里会残留大量短时等待噪音
为什么不能用时间字符串而要用快照ID调用 awrddrpt
时间字符串依赖 NLS_DATE_FORMAT、会话时区、数据库时区三重解析，哪怕只差 17 秒，就可能导致快照边界错位。AWR 报告里 “Avg Active Sessions” 这类指标是按实际快照间隔归一化的，17 秒偏差在高波动负载下可导致 AAS 偏差超 15%。
- 正确做法：在 SQL*Plus 中用
DEFINE显式传入快照 ID，例如：DEFINE START_SNAP_ID = 12345、DEFINE END_SNAP_ID = 12350、DEFINE BASELINE_START_SNAP_ID = 12000、DEFINE BASELINE_END_SNAP_ID = 12005 - 必须同步指定
dbid和inst_num：RAC 环境下不填inst_num默认只取当前连接实例；多租户环境不填dbid可能混入其他 PDB 数据 -
awrddrpt不支持交互式输时间，强行输'2026-07-18 14:00'类字符串，脚本大概率静默 fallback 到默认快照范围，且不报错
看对比报告时盯哪几行才不跑偏
别从 Top SQL 开始翻——高峰天然 SQL 执行次数多，低峰天然单次耗时高，直接比 Elapsed Time per Execution 会误判。真正该先扫的是归一化后带 %Diff 的核心负载指标。
- 重点看
DB Time per Txn和DB CPU per Txn：如果前者 ↑35% 而后者仅 ↑2%，说明高峰主要卡在 I/O 或锁上，不是 CPU 瓶颈 - 关注
Physical Reads per Txn和Buffer Gets per Txn的比值变化：比值↑说明缓存效率下降，可能 Buffer Cache 被挤占或热点数据未固化；比值↓但绝对值↑，可能是高峰批量读取更多数据，属正常 - 检查
enq: TX - row lock contention的Waits per Txn：低峰为 0.02、高峰升到 1.8，+8900%，哪怕它在 Top 5 外，也得立刻结合v$active_session_history查阻塞链 - 忽略所有
/Sec行：高峰事务量是低峰的 8 倍，Execs per Sec看起来降了 40% 是假象；只信per Txn或Total列
最易被跳过的点：对比前没确认两个时段是否属于同一 con_name。连在 CDB$ROOT 下跑 awrddrpt，默认查整个集群，PDB 间的负载会被平均掉——尤其当某个 PDB 在高峰扛了 90% 流量时，对比结果毫无意义。
