靠谱的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，而是确保它在三个月后、版本升级后、跨集群迁移后，依然能准确代表那个“正常态”。这需要定期验证，而不是建完就扔。
