Oracle数据库性能基线怎么建？利用AWR快照管理

AWR快照默认保留多久？怎么查和改

在构建性能基线之前，有一个细节常常被忽略，却至关重要：你手头的AWR快照数据，究竟覆盖了多长时间？Oracle默认会保留8天的快照数据，这个信息记录在dba_hist_wr_control视图中。如果没确认这一点就直接使用，很可能选用了不完整或已过期的快照范围，导致基线数据失真，后续的性能对比也就失去了意义。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

那么，如何确认和调整这个设置呢？

查看当前配置：

SELECT snap_interval, retention FROM dba_hist_wr_control;

执行这条命令，你会看到类似+00000 01:00:00.0（表示每小时生成一次快照）和+00008 00:00:00.0（表示保留8天）的结果。这就是你数据库的现状。

调整保留时间：

如果觉得8天不够用，比如希望延长到30天以便分析月度性能趋势，可以执行：

EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 43200);

这里需要注意，参数单位是分钟，43200就是30天（30 * 24 * 60）的计算结果。这个操作需要DBA权限，并且修改只对后续生成的快照生效，已有的历史快照不会被自动延长保留期。

• 避开高峰期操作：执行MODIFY_SNAPSHOT_SETTINGS过程会触发一次内部工作负载仓库控制表的刷新，可能带来短暂的锁争用，因此务必不要在业务高峰时段进行。
• 警惕磁盘空间：如果将retention设置得过大，而SYSAUX表空间不足，AWR的自动清理机制可能会失败。此时DBA_HIST_WR_CONTROL视图的STATUS字段可能变为0（异常），需要手动介入处理。
• 快照间隔建议：对于生产库，快照间隔（snap_interval）通常设为60分钟是平衡点。如果需要进行小时级的精细性能归因，可以临时调整为30分钟，但不建议长期设置为15分钟——这会使AWR写入压力倍增，并显著加速SYSAUX表空间的增长。

怎么从 AWR 快照里抽一组“健康”基线数据

确定了快照的保留范围，下一步就是从中筛选出合适的“健康”数据来建立基线。基线不是任意两个时间点的快照组合，它必须代表业务负载稳定、没有异常等待事件、且未发生计划外维护的典型时段。直接查询DBA_HIST_SNAPSHOT只能看到时间戳，真正的“健康”判断，需要结合DBA_HIST_SYSMETRIC_SUMMARY和DBA_HIST_SYSTEM_EVENT等动态性能视图。

这里提供一个快速筛查的思路：

SELECT snap_id, begin_interval_time, end_interval_time,
       ROUND(a verage_wait_time_per_sec, 2) a vg_await,
       ROUND(db_time_per_sec, 2) db_time_s
FROM dba_hist_sysmetric_summary
WHERE metric_name = 'Database Time Per Second'
  AND snap_id IN (
    SELECT snap_id FROM dba_hist_snapshot
    WHERE begin_interval_time BETWEEN SYSDATE-7 AND SYSDATE-1
  )
ORDER BY db_time_s DESC;

通过这个查询，可以观察db_time_s（每秒数据库时间）的波动是否平缓。那些a vg_await（平均等待时间）持续高于50毫秒的快照，通常意味着存在严重的I/O或锁争用，不适合纳入基线。

• 关注变化率而非绝对值：不要只看DB_TIME的绝对值高低，重点考察相邻快照间其变化率。如果某个快照的DB_TIME相比前一个突增了3倍以上，那么这个快照大概率包含了异常事件。
• 利用ASH数据回溯：可以借助DBA_HIST_ACTIVE_SESS_HISTORY进一步分析Top SQL。如果发现某个快照周期内，log file sync（日志文件同步）等待事件占比超过20%，这个快照也应被排除在基线之外。
• 基线时间跨度：一个稳健的基线至少应跨越3个连续的工作日（避开节假日）。每天选取3到5个典型业务时刻的快照（例如上午10点、下午2点、傍晚6点），同时注意避开凌晨的统计信息收集或备份作业时段。

创建命名基线后，为什么查询 DBA_HIST_BASELINE 看不到数据

按照流程创建了命名基线，但查询DBA_HIST_BASELINE视图却空空如也？这种情况并不少见。首先要理解，创建基线这个动作本身并不会生成新的快照，它只是在WRH$_BASELINE底层表中记录下起始和结束的snap_id范围。如果指定的快照ID已经被自动清理（例如之前缩短过保留时间），或者这些ID根本不存在，那么CREATE_BASELINE过程可能会静默失败，而DBA_HIST_BASELINE视图自然也就没有记录。

正确的创建和验证步骤应该是这样的：

BEGIN
  DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(
    start_snap_id => 12345,
    end_snap_id   => 12355,
    baseline_name => 'PROD_PEAK_MON_TO_FRI',
    expiration    => 90
  );
END;

执行后，立即进行验证：

SELECT baseline_id, baseline_name, start_snap_id, end_snap_id
FROM dba_hist_baseline
WHERE baseline_name = 'PROD_PEAK_MON_TO_FRI';

• 执行前确认快照存在：在调用CREATE_BASELINE之前，务必先用SELECT COUNT(*) FROM dba_hist_snapshot WHERE snap_id BETWEEN 12345 AND 12355;确认指定的快照ID范围确实存在且未被清除。
• 理解过期参数：expiration参数的单位是天，设为NULL表示基线永不过期。虽然方便，但并不推荐，因为长期积累大量不过期的基线会导致AWR相关查询性能下降。
• 排查空结果：如果查询结果仍为空，需要检查两个地方：一是DBA_HIST_WR_CONTROL.STATUS是否为1（表示AWR功能正常）；二是当前操作的用户是否拥有SELECT_CATALOG_ROLE等必要的权限。

用基线对比报告（awrddrpt.sql）时，为什么输出全是空白或报 ORA-13634

当你终于准备好基线数据，兴冲冲地运行awrddrpt.sql脚本想生成一份对比报告，却可能遇到输出空白文件或恼人的ORA-13634错误（“指定的基线不存在”）。这通常不是基线本身的问题，而是脚本运行环境或参数细节导致的。

awrddrpt.sql是一个SQL*Plus脚本，其运行依赖于正确的环境变量和连接权限。ORA-13634错误本质上就是系统找不到你指定的基线，常见原因有三：基线名称大小写不匹配、基线未在当前数据库实例中正确注册、或者脚本是在Pluggable Database（PDB）中运行而非在CDB$ROOT容器中。

安全的执行方式应遵循以下步骤：

1. 连接到正确的容器：首先，确保登录到CDB$ROOT（而不是某个PDB）：

   sqlplus / as sysdba

2. 显式指定所有参数：然后运行脚本，并仔细输入每一步的提示：

   @?/rdbms/admin/awrddrpt.sql
   -> 输入报告类型：text
   -> 输入数据库 ID（查 v$database.dbid）
   -> 输入实例号（查 v$instance.instance_number）
   -> 输入基线名：'PROD_PEAK_MON_TO_FRI'（必须完全一致，含大小写）
   -> 输入比较基线名：'PROD_OFFHOUR_BASELINE'

• 注意名称格式：避免直接从OEM或云控制台复制粘贴基线名称，这些界面有时会引入不可见的空格或全角字符，导致脚本无法识别。
• 多租户环境：如果数据库启用了多租户架构，awrddrpt.sql必须在CDB$ROOT下运行，否则脚本无法跨PDB汇总所需的AWR数据。
• 检查输出路径权限：报告默认输出到当前目录。请确认Oracle操作系统用户对该目录拥有写入权限，否则可能会生成一个空的报告文件。

说到底，建立基线最难的部分并非创建动作本身，而在于持续的校准和维护。业务逻辑的变更、SQL执行计划的漂移、乃至硬件的升级，都可能让旧的基线逐渐失去参考价值。因此，一个值得推荐的做法是：至少每月一次，利用最近7天的快照数据重新评估基线的健康度，这比单纯地存档一份历史基线要有价值得多。