归档卡死时ASH无法直接看到ARCH进程，需通过LGWR和前台会话等待log file switch类事件定位阻塞源头；必须用GV$ASH查RAC全局影响，并结合v$archive_dest_status的error字段确认根因。
归档卡死时，ASH无法直接看到ARCH进程本身，但能精准暴露它引发的连锁阻塞——关键不是查“谁没归档”，而是查“谁被归档卡住”。
为什么不能直接查ARCH在等什么
ARCH是后台进程，v$active_session_history默认只采样前台会话和部分活跃后台进程（如DBWR、LGWR），ARCH多数时间处于rdbms ipc message空闲态，ASH里几乎不出现。你搜event LIKE '%arch%'基本为空。
真正要盯的是归档卡住后引发的“下游反应”：
- LGWR因log buffer满而卡在
log file switch (archiving needed) - 前台会话因无法获取新日志块而卡在
log file switch (checkpoint incomplete)或enq: SQ - contention - 大量会话状态变为
WAITING且event集中在log file switch类事件，sql_id分散但session_state高度一致
必须用GV$ACTIVE_SESSION_HISTORY查RAC跨节点影响
归档路径若挂载在共享存储（如ASM diskgroup或NFS），一个节点ARCH卡死可能拖垮整个RAC。单查v$active_session_history只能看到本节点症状，漏掉根因节点。
立即执行：
SELECT sample_time, instance_number, session_id, event, blocking_session,
final_blocking_session, final_blocking_instance, sql_id
FROM gv$active_session_history
WHERE sample_time > SYSDATE - INTERVAL '5' MINUTE
AND event LIKE 'log file switch%'
AND session_state = 'WAITING';重点看final_blocking_instance是否非空且指向某特定节点——那个节点大概率就是ARCH卡死的源头。
从ASH反推归档瓶颈点的三个信号
归档卡死不是孤立事件，ASH里必然留下三类强关联痕迹：
-
event = 'log file switch (archiving needed)'样本数突增（对比基线，通常>10倍）且持续集中在同一sample_time窗口 - 对应时段
v$archived_log中first_time与next_time差值拉长（如正常2秒，现在卡在300秒以上），需立刻查：SELECT MAX(next_time - first_time) * 24 * 60 FROM v$archived_log WHERE first_time > SYSDATE - 1/24; - 若归档目标是文件系统，ASH中同时出现大量
write complete waits或free buffer waits，说明归档写慢已传导至DBWR和缓冲区管理
别跳过对v$archive_dest_status的即时验证
ASH告诉你“哪里卡住了”，但不告诉你“为什么卡”。查完ASH后，必须立刻切到疑似根因节点，运行：
SELECT dest_id, status, error, target, schedule,
TRANSLATE(archiver, ' ', '_') archiver_state,
(SELECT COUNT(*) FROM v$log WHERE status = 'CURRENT') curr_logs
FROM v$archive_dest_status
WHERE status != 'DEFERRED' AND bind = 'ENABLED';重点关注：
-
status = 'ERROR'且error含ORA-00257（归档空间满）或ORA-19504（OS层写失败） -
archiver_state = 'FAILED'或为空（ARCH进程实际已crash） -
curr_logs > 1且schedule = 'STOPPED'（归档被手动停过，未恢复）
归档卡死的根因往往藏在v$archive_dest_status.error里，但这个字段只有在ASH确认阻塞范围后才值得深挖——否则容易陷入盲目清理归档目录的误区。
