CREATE_BASELINE必须指定快照范围而非时间范围，因其参数为start_snap_id和end_snap_id，Oracle以快照ID为唯一锚点，时间仅为辅助查询手段；传入无效ID或顺序错误将报ORA-13516。
CREATE_BASELINE 为什么必须指定快照范围而不是时间范围
因为 dbms_workload_repository.create_baseline 接收的是 start_snap_id 和 end_snap_id，不是日期。oracle 内部用快照 id 做唯一锚点，时间只是辅助查询手段——你查不到快照 id 就没法建基线，哪怕时间看起来“很准”。
常见错误现象：ORA-13516: AWR operation failed: invalid snapshot range，基本都是传了不存在的快照 ID，或 end_snap_id 小于 start_snap_id。
- 先查目标时间段内有哪些快照：
SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot WHERE begin_interval_time >= TIMESTAMP '2024-05-10 08:00:00' AND end_interval_time
- 确认这些快照没被自动清理（
dba_hist_wr_control.retention默认 8 天，但可能被 DBA 调小） -
start_snap_id和end_snap_id必须属于同一数据库实例（dbid），跨 RAC 节点混用会静默失败
如何确保基线只保留“正常”指标不带干扰噪声
AWR 基线本身不做过滤，它只是把指定快照区间的原始数据打个包存进 WRM$_BASELINE。所谓“正常”，得靠你选快照时人工排除异常段——比如避开计划外的批处理、网络抖动、或刚重启后的暖机期。
使用场景：日常监控中发现某天早高峰响应变慢，想对比“上周同时间段的健康表现”，就得手动跳过上周三那个因备份导致 I/O 飙高的快照段。
- 别依赖单个快照：至少选连续 3–5 个快照，避免偶然尖峰污染基线均值
- 用
dba_hist_sysmetric_summary快速扫一眼 CPU、I/O、DB Time 是否平稳，比翻 AWR 报告快得多 - 如果业务有明确低峰期（如凌晨 2–4 点），优先选这个窗口，它天然抗干扰
CREATE_BASELINE 的 name 和 expiration 参数怎么设才不踩坑
name 是基线唯一标识，不能重复；expiration 控制自动清理时间，但注意：它只影响基线元数据，不影响底层快照——快照仍受 AWR 保留策略约束。
容易踩的坑：expiration => NULL 表示“永不过期”，但实际会卡在 AWR 快照被删那一刻，基线变成“空壳”，后续 DBMS_WORKLOAD_REPOSITORY.SELECT_BASELINE_METRICS 查不到数据却无报错。
-
name建议含日期和业务含义，例如'app_normal_20240510_morning'，别用'baseline1'这类命名 -
expiration设为具体天数（如30），比NULL更可控；若真要长期用，定期用DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE更新过期时间 - 创建后立刻查
dba_hist_baseline确认baseline_type = 'STATIC'且status = 'ENABLED'
基线建好了，但 AWR 报告里不显示？检查这三点
基线不会自动出现在任何默认 AWR 报告里，必须显式指定。很多人建完就去跑 awrrpt.sql，发现对比栏还是空的——不是没生效，是根本没调用。
性能影响：基线本身几乎零开销，但生成带基线对比的报告（尤其跨多天）会多扫一遍历史快照表，比普通报告慢 20%–40%，别在高峰期批量跑。
- 生成 HTML 报告时，在 SQL*Plus 里执行
@?/rdbms/admin/awrrpti，交互式选择 “Baseline Comparison” 类型 - 用 PL/SQL 调用
DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML时，必须传入baseline_name参数，不能只传dbid/inst_num - 确认当前用户有
SELECT_CATALOG_ROLE，否则dba_hist_baseline查不到，连带基线对比功能不可见
最常被忽略的一点：基线的 dbid 和你要分析的 AWR 报告的 dbid 必须一致。RAC 或 Data Guard 环境下，一不留神就选错实例，结果什么对比数据都出不来。
