AWR快照默认保留8天；查用SELECT snap_interval, retention FROM dba_hist_wr_control；改用EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention=>43200)（单位分钟）。
AWR快照默认保留多久？怎么查和改
oracle 默认保留 awr 快照 8 天（对应 dba_hist_snapshot 中的 snap_interval 和 retention），但实际基线建设前必须确认当前值，否则用错快照范围会导致基线失真。
查当前配置：
SELECT snap_interval, retention FROM dba_hist_wr_control;返回类似
+00000 01:00:00.0（1 小时一拍）和 +00008 00:00:00.0（8 天保留）。
改保留时间（比如延长到 30 天）：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 43200);
注意单位是分钟，
43200 = 30 <em> 24 </em> 60。这个操作需 DBA 权限，且修改后只影响后续快照，旧快照不会自动延长。
- 别在业务高峰期执行
MODIFY_SNAPSHOT_SETTINGS，它会触发一次内部 WR 控制表刷新，短时加锁 - 如果
retention设得过大而磁盘空间不足，AWR 自动清理会失败，DBA_HIST_WR_CONTROL的STATUS字段可能变0（异常），需人工干预 - 快照间隔（
snap_interval）建议生产库设为 60 分钟；若要做小时级性能归因，可临时调到 30 分钟，但别长期设为 15 分钟——写入压力翻倍，SYSAUX表空间增长明显
怎么从 AWR 快照里抽一组“健康”基线数据
基线不是随便挑两个快照——得选业务负载稳定、无异常等待、无计划外维护的窗口。直接查 DBA_HIST_SNAPSHOT 只能看到时间戳，真正判断“健康”得结合 DBA_HIST_SYSMETRIC_SUMMARY 和 DBA_HIST_SYSTEM_EVENT。
快速筛查方法：
SELECT snap_id, begin_interval_time, end_interval_time,
ROUND(average_wait_time_per_sec, 2) avg_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 波动是否平缓（标准差 avg_await > 50 的快照（说明有严重 I/O 或锁争用）。
- 别只看
DB_TIME绝对值，重点看相邻快照间变化率；突增 3 倍以上大概率含异常 - 用
DBA_HIST_ACTIVE_SESS_HISTORY回溯 Top SQL：如果某快照里log file sync等待占比超 20%，这个快照不能进基线 - 基线至少跨 3 个连续工作日（非节假日），每天取 3–5 个典型快照（如 10:00、14:00、18:00），避开凌晨统计作业时段
创建命名基线后，为什么查询 DBA_HIST_BASELINE 看不到数据
创建基线本身不生成新快照，只是在 WRH$_BASELINE 表里记下起止 snap_id 范围。如果指定的快照已被清理（比如 retention 缩短过），或快照 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';
- 执行前务必用
SELECT COUNT(*) FROM dba_hist_snapshot WHERE snap_id BETWEEN 12345 AND 12355;确认快照存在且未被 purge -
expiration单位是天，设为NULL表示永不过期，但不推荐——长期不清理的基线会让 AWR 查询变慢 - 如果返回空行，检查
DBA_HIST_WR_CONTROL.STATUS是否为 1（正常），以及当前用户是否有SELECT_CATALOG_ROLE
用基线对比报告（awrddrpt.sql）时，为什么输出全是空白或报 ORA-13634
awrddrpt.sql 是 SQL*Plus 脚本，依赖环境变量和当前连接用户权限。ORA-13634 本质是「找不到指定基线」，常见于三种情况：基线名大小写不匹配、基线未在当前数据库实例注册、或脚本运行时连的是 PDB 而非 CDB$ROOT。
安全执行方式： 1. 登录 CDB$ROOT（不是任意 PDB）：
sqlplus / as sysdba2. 运行脚本并显式指定参数：
@?/rdbms/admin/awrddrpt.sql -> 输入报告类型：text -> 输入数据库 ID（查 <code>v$database.dbid</code>） -> 输入实例号（查 <code>v$instance.instance_number</code>） -> 输入基线名：'PROD_PEAK_MON_TO_FRI'（必须完全一致，含大小写） -> 输入比较基线名：'PROD_OFFHOUR_BASELINE'
- 别用 OEM 或云控制台导出的基线名直接粘贴——可能带不可见空格或全角字符
- 如果数据库启用了多租户，
awrddrpt.sql必须在 CDB$ROOT 下运行，否则无法跨 PDB 汇总 AWR 数据 - 报告输出路径默认是当前目录，确保 Oracle 用户对该路径有写权限，否则生成空文件
基线真正的难点不在创建，而在持续校准：业务逻辑变更、SQL 执行计划漂移、硬件升级都会让旧基线失效。每月至少用最近 7 天快照重跑一次基线健康度检查，比单纯存档更有价值。
