直接看Top 5 Timed Foreground Events中log file sync或log file parallel write占比超20%且多快照持续出现，结合Redo Nowait%
AWR里怎么看归档慢是不是主因
直接看 top 5 timed foreground events 页面，如果 log file sync 或 log file parallel write 占 db time 比例超过 20%，且持续出现在多个快照区间，基本可锁定归档写入瓶颈。注意：这两个事件高发时，db cpu 通常不高，但 db time 会显著高于 db cpu——这是典型的“等 i/o”而非“算不动”。
别只盯着等待事件排序，还要交叉验证：IO Stats 页里的 Redo Nowait % 若低于 99.5%，说明 redo 写入频繁受阻；Instance Efficiency Percentages 中的 Buffer Nowait % 如果也同步下降（比如掉到 95% 以下），往往意味着 buffer cache 压力传导到了 redo 路径。
确认归档日志空间是否真的满了
AWR 报告本身不直接显示归档空间使用率，但能提供关键线索：Report Summary 页顶部的 Database Status 若显示 HANGING 或 QUIESCED，结合 Alert Log 时间戳比对 AWR 快照区间，大概率是归档满触发的挂起。此时必须立刻查 OS 层：
-
df -h查归档目标路径（通常是$ORACLE_BASE/fast_recovery_area或自定义LOG_ARCHIVE_DEST_1） -
ls -lt /path/to/archive | head -20看最近归档文件时间是否中断（比如卡在几小时前） - 若用 ASM，进
asmcmd执行lsdg，关注USABLE_FILE_MB是否为 0 或负值
注意：AWR 报告中 Wait Event 出现大量 ARCHIVE LOG WAIT（Oracle 11g 实际不显式报这个事件名，但 log file sync + enq: SQ - contention 组合出现，就是归档进程被堵死的典型信号）。
为什么AWR报告生成慢或缺失可能干扰判断
归档满导致挂起时，AWR 自身采集也可能失败——因为 MMON 进程写 SYSAUX 表需要写 redo，而 redo 写不下去，整个 AWR 快照就卡住。现象是：dba_hist_snapshot 里最近几个小时没新记录，或者 SELECT * FROM dba_hist_wr_control 显示 RETENTION 正常但实际快照没清理。
这时别硬等 AWR，优先执行：
-
SELECT status, error FROM v$archive_dest WHERE dest_id = 1;—— 直接看归档目标状态 -
SELECT * FROM v$archived_log WHERE first_time > SYSDATE - 1/24 ORDER BY first_time DESC;—— 确认最后成功归档时间 -
SELECT event, wait_time_micro FROM v$session_event WHERE event LIKE 'log%';—— 实时抓前台会话在等什么
AWR 报告缺失不是诊断终点，而是问题已进入严重阶段的提示。
清理归档后如何验证挂起解除
删完归档文件、执行 CROSSCHECK ARCHIVELOG ALL 和 DELETE NOPROMPT EXPIRED ARCHIVELOG ALL 后，不能只看数据库“能连上”，要盯三个实时指标：
-
v$sysstat中redo log space requests计数应停止增长（每秒为 0） -
v$archive_dest_status的STATUS列变回VALID，ERROR列为空 - 新开一个会话执行
ALTER SYSTEM SWITCH LOGFILE;，观察是否秒级完成，且无ORA-00313或ORA-16072报错
真正解除挂起的标志不是应用恢复响应，而是 LGWR 和 ARCH 进程不再出现 WAITING 状态——用 SELECT pid, spid, program, state FROM v$process WHERE program LIKE '%LGWR%' OR program LIKE '%ARC%'; 验证。
