如何配置AWR基线Baseline_对比不同时间段AWR性能报告排查衰退-Oracle-PHP中文网

靠谱的fixed baseline需选业务平稳、负载稳定的连续时段（如工作日10:00–12:00），用snap_id创建以避时区问题；须设合理expiration防AWR清理失败；创建后验证baseline_type='STATIC'且时间窗口准确；其对比比单看AWR报告更准，因能归一化指标、识别隐性变化；注意时钟漂移与版本升级影响，需定期验证有效性。

怎么创建一个靠谱的 fixed baseline

基线不是随便选两个快照就能用的，它必须代表“系统正常、业务典型、负载稳定”的时段。否则对比结果全是噪音——比如拿凌晨空闲期当 baseline 去比白天高峰，db time 差 10 倍也纯属正常，根本看不出性能衰退。

实操建议：

先查 dba_hist_snapshot，挑出业务平稳运行的连续时间段（比如工作日 10:00–12:00，连续 4 小时无批处理、无发布、无告警）
用 start_snap_id 和 end_snap_id 创建最稳妥，避免时间戳格式/时区问题；若用 start_time/end_time，务必确认数据库时区和会话时区一致（SELECT SESSIONTIMEZONE, DBTIMEZONE FROM DUAL）
别省事设 expiration => NULL：长期不清理的 baseline 会锁住对应快照，导致 AWR 自动清理失败，表空间悄悄涨满
创建后立刻查 dba_hist_baseline_details，确认 baseline_type = 'STATIC' 且时间窗口和你预期完全吻合

为什么 baseline 对比比单纯看两个 AWR 报告更准

直接打开两份 AWR 报告肉眼对比 Top SQL 或等待事件，容易漏掉关键变化——比如某条 SQL 的执行次数翻倍了但单次耗时降了，总 DB Time 却没变；或者 Buffer Gets 上升 30%，但物理读只涨 2%，说明是逻辑结构或绑定变量问题，不是 I/O 瓶颈。

baseline 的价值在于它把“正常态”固化为统计模型，AWR Compare Period Report（即 awrddrpt）会自动对齐时间粒度、归一化指标、高亮显著差异项（比如 p-value

常见错误现象：

用 @?/rdbms/admin/awrrpt 分别生成两份报告再手动比——指标口径可能不一致（如快照间隔不同导致 per second 计算偏差）
对比时没指定同一 dbid 和 inst_num，尤其在 RAC 环境下，误把实例 1 的 baseline 和实例 2 的问题时段对比，结果毫无意义
忽略 baseline 的统计覆盖范围：一个 2 小时 baseline 包含 24 个快照，而问题时段只取了其中 3 个快照，对比权重严重失衡

如何用命令行快速生成 baseline 对比报告（不依赖 OEM）

OEM 界面点点点很直观，但生产环境常需脚本化、定时化或跳过 GUI 依赖。核心是调用 awrddrpt 脚本，但它不像 awrrpt 那样交互友好，参数顺序和类型必须严格匹配。

实操建议：

进入 SQL*Plus 后直接运行：@?/rdbms/admin/awrddrpt，它会引导你选格式、DBID、实例号、baseline 名称（注意：这里填的是 baseline_name，不是 snap_id）、对比时段的起止 snap_id
如果要静默生成（比如写进巡检脚本），改用 awrddrpt.sql 并传参：@?/rdbms/admin/awrddrpt.sql html 34567890123 1 0 mybase 1234 1245（顺序不能错：格式、DBID、INST_NUM、BASELINE_ID、START_SNAP、END_SNAP）
别用 awrrpti 或 awrgrpt 替代——它们只做单时段报告，无法触发 baseline 统计模型
生成的 HTML 报告里重点看 “Comparison Summary” 和 “SQL Ordered by Delta DB Time” 这两节，衰退通常就藏在这儿

最容易被忽略的 baseline 兼容性陷阱

基线本身不是“快照集合”，而是基于快照数据训练出的一组统计基准值（均值、标准差、分位数）。Oracle 在 11g+ 引入 moving window baseline 后，fixed baseline 的行为其实有隐式约束：

baseline 时间段内的快照必须全部在 AWR 保留期内——如果 AWR 只保留 8 天，但你想建 3 月 1 日的 baseline，到 3 月 10 日就失效了，哪怕你设了 expiration => 90
VPS 或超融合环境要注意时钟漂移：宿主机时间跳变会导致 begin_interval_time 错乱，baseline 时间窗口“看起来对”，实际快照 ID 对不上；建议创建前跑一次 ntpdate -q pool.ntp.org 校验
升级数据库版本后，旧 baseline 仍可用，但新版本的自适应阈值（Adaptive Thresholds）功能默认只认 moving window baseline，fixed baseline 不参与动态告警——这点文档很少提，却直接影响监控有效性

真正麻烦的从来不是建 baseline，而是确保它在三个月后、版本升级后、跨集群迁移后，依然能准确代表那个“正常态”。这需要定期验证，而不是建完就扔。