应根据问题持续时间选择工具：瞬时问题（如“刚卡两分钟”）用ASH（每秒采样，内存保留约1小时），长期趋势（如“三天变慢”）用AWR（每小时快照，默认保留7天）；须严格匹配时间窗口、验证ARCHIVELOG模式、RECYCLEBIN开关及SGA配置。
oracle数据库系统检查清单不是模板填空，而是分层验证动作；awr和ash不是报告生成完就结束，关键在时间窗口匹配与采样粒度理解。
怎么快速判断该用ASH还是AWR
看问题持续时间：如果用户刚反馈“刚才卡了两分钟”，立刻查 V$ACTIVE_SESSION_HISTORY 或跑 @?/rdbms/admin/ashrpt.sql；如果问题是“最近三天响应越来越慢”，必须用 @?/rdbms/admin/awrrpt.sql 拉快照区间。ASH内存采样是每秒一次，但只保留约1小时（受 ASH buffers 内存大小限制，常见为15MB左右）；AWR磁盘落盘是每小时一次，默认保留7天，数据来自 WRH$_ACTIVE_SESSION_HISTORY 等历史表。
容易踩的坑：
- 用ASH查昨天的问题——
V$ACTIVE_SESSION_HISTORY重启库或内存刷满后就清空，不可回溯 - 用AWR查5分钟内的瞬时尖刺——默认1小时采样间隔，可能根本没捕获到那5分钟的高负载
- 在非DBA账号下执行报告脚本——报错
SP2-0310: unable to open file "ashrpt.sql"，因为脚本路径依赖$ORACLE_HOME/rdbms/admin/，且需有SELECT_CATALOG_ROLE权限
生成ASH报告时必须核对的三个时间参数
执行 @?/rdbms/admin/ashrpt.sql 后，系统会要求输入起始时间、持续时长和输出格式。这里的“起始时间”不是服务器当前时间，而是ASH内存中仍存在的最早可采样时间点——可通过 SELECT MIN(sample_time) FROM v$active_session_history; 查。持续时长单位是秒，别误输成分钟；若想覆盖完整故障窗口，建议多扩30秒，避免刚好卡在采样边界丢数据。
实操建议：
- 先运行
SELECT TO_CHAR(MIN(sample_time), 'YYYY-MM-DD HH24:MI:SS'), TO_CHAR(MAX(sample_time), 'YYYY-MM-DD HH24:MI:SS') FROM v$active_session_history;确认可用时间范围 - 输入起始时间格式必须严格匹配示例，如
2026-04-12/18:30:00，不能写成2026-04-12 18:30（缺秒会报错） - 输出选
html而非text：HTML版带交互式Top SQL排序和等待事件堆叠图，text版只有扁平列表
AWR快照范围选错会导致报告完全失效
执行 @?/rdbms/admin/awrrpt.sql 时，“选择快照范围”步骤实际是在查 DBA_HIST_SNAPSHOT 表。默认显示所有快照，但真正有效的只有那些成功采集的——注意看 STATUS 列是否为 0（正常），1 表示失败（常见于快照生成时实例异常）。起始快照号和结束快照号必须来自同一实例（DBID 相同），跨实例混选会生成空报告或报错 ORA-13516。
性能影响提示：
- 快照范围过大（如跨7天）会导致报告生成超时，建议单次不超过24小时
- 若需对比不同时段，不要拼一个超长报告，而应分别生成两个报告，再人工比对
DB Time、Logical Reads Per Sec等核心指标 - 修改默认保留策略用
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS，但retention参数单位是分钟，设成10080才是7天，别直接写7
巡检清单里最容易被跳过的三项硬性检查
很多DBA生成完AWR/ASH就以为完成巡检，但以下三项不验证，报告结论可能全错：
-
ARCHIVELOG模式状态：非归档模式下，部分后台进程行为异常，ASH中可能缺失归档等待事件，AWR中Redo Generated Per Sec指标失真 -
RECYCLEBIN开关：若关闭（recyclebin=off），闪回查询类诊断无法使用，影响ASH中部分SQL绑定信息追溯 -
SGA_TARGET与SGA_MAX_SIZE关系：若前者远小于后者，说明内存未充分启用，AWR中Buffer Cache Hit Ratio可能虚高，掩盖真实I/O压力
这些参数不在AWR/ASH报告正文里，必须单独查 V$DATABASE、V$PARAMETER 和 V$SGASTAT 视图确认。漏掉任一，后续所有性能归因都可能是错的。
