如何通过Oracle AWR分析不同时段的负载差异_使用AWR Compare报告-Oracle-PHP中文网

唯一靠谱的跨时段负载对比方式是直接用awrddrpt生成compare period report；手动比对两份awrrpt报告因快照不对齐、实例范围不一致、dbid混淆等导致指标口径失真，结果无效。

直接用 awrddrpt 生成 compare period report 是唯一靠谱的跨时段负载对比方式；手动拉两份 awrrpt 报告再逐项比对，指标口径、快照对齐、实例范围全不可控，结果基本无效。

为什么不能手动对比两份 awrrpt 报告

AWR 报告里的关键指标（如 Avg Active Sessions、DB CPU Per Sec、Physical Reads Per Sec）都是基于快照间隔归一化计算的。如果两个报告的快照起止时间不对齐（比如一个从 10:00:12 开始，另一个从 10:00:47 开始），哪怕只差 35 秒，在高波动负载下，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 下必须明确，不填 = 只取当前连接实例，无法做跨实例横向比
num_days 或 start_snap_id/end_snap_id：推荐用 start_snap_id 和 end_snap_id，彻底规避时区、NLS_DATE_FORMAT、会话时区不一致导致的时间解析错位
report_type：必须为 TEXT 或 HTML，不支持 XML 输出（该类型无标准化结构，awrddrpt 不处理）

示例（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。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

Compare Report 里真正要看的负载指标只有三个

Report Summary → Comparison Section 会列出几十项 delta，但 90% 都是干扰项。业务负载是否真实升高，只看这三个归一化后的每秒指标：

Avg Active Sessions：> CPU 核数即存在排队，是负载最直观反映；注意排除后台进程影响（DB CPU 中若 ora_mmon_ 占比突增，需结合 v$session 过滤）
DB CPU Per Sec：纯操作系统级 CPU 消耗，排除 I/O 等待；若该值未涨但 AAS 涨了，说明瓶颈在锁、latch 或网络延迟
Physical Reads Per Sec：比总量稳定，能识别持续 IO 压力；单次大导入导致的 Physical Reads 总量飙升，在 per sec 维度会被平滑，不构成误判

其他如 DB Time、Logical Reads、Executions 必须结合业务量解释——它们本身不是负载指标，只是业务行为的结果。

baseline 时间窗口覆盖不足会导致对比失效

一个 fixed baseline 若只包含 3 个快照（比如 2 小时内仅采了 3 次），而问题时段有 12 个快照，Compare Report 实际是以 baseline 的 3 个点去拟合问题时段的 12 个点，统计权重严重失衡。AWR 内部会用线性插值补全，但插值结果在高波动场景下完全不可信。

实操建议：

baseline 至少覆盖连续 4 小时，且快照间隔 ≤ 30 分钟（即 ≥ 8 个快照）
查 dba_hist_baseline_details 确认 baseline_type = 'STATIC' 且 duration_days >= 0.16（≈ 4 小时）
若历史 baseline 快照稀疏，宁可不用，改用最近 5 个工作日同时间段的滚动均值（用 awrrpt 批量提取后 Excel 计算）

时钟漂移、版本升级、AWR 保留策略变更都会让旧 baseline 失效，没有一劳永逸的 baseline —— 它本质是快照数据的快照，过期就得重校准。