确认arch进程卡死需先查主库：v$managed_standby中arch状态为connected但sequence#超5分钟不更新，且v$archive_dest_status中dest_id=2的error非空（如ora-16038/ora-19809）或status为error/deferred，再结合alert日志中“archiving not possible”等报错即可确诊。
oracle 11g data guard 同步停止，如果根源是主库 arch 进程卡死（而非备库 mrp0 或网络问题），直接重启数据库或杀进程大概率无效；必须先确认卡死原因，再针对性干预归档路径和日志流状态。
怎么确认是 ARCH 进程卡死，而不是其他环节出问题
别一上来就查备库。先在主库上快速验证：ARCH 是否真卡住，还是只是“看起来没动”：
- 执行
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('ARCH', 'RFS', 'MRP0');—— 若ARCH的STATUS是CONNECTED但SEQUENCE#长时间不更新（比如 >5 分钟没变），且RFS在备库端也无新日志接收记录，说明归档根本没发出去 - 查
V$ARCHIVE_DEST_STATUS：运行SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;，若STATUS为ERROR或DEFERRED，ERROR字段含ORA-16038、ORA-19809或路径不可写等字样，就是ARCH被阻塞的铁证 - 检查主库 alert 日志最近 10 分钟是否有
ARCn: Archiving not possible. Shutting down.或反复出现Archived Log added for thread X sequence Y后再无下文
为什么不能直接 kill -9 ARCH 进程或重启实例
ARCH 是后台关键进程，Oracle 不允许手动 kill 它——强行终止会触发 LGWR 挂起，进而导致所有 DML hang 住，业务瞬间中断。更危险的是，若归档目标配置了 MANDATORY 属性，LGWR 会一直等待归档完成，整个主库写操作冻结。
-
ARCH卡死本质是归档路径写入失败，不是进程崩溃；kill 它只会让 Oracle 自动拉起一个新ARCH，但新进程仍卡在同一位置 - 重启实例成本太高，且无法解决底层空间/权限/ASM failgroup 不可用等真实问题
- 真正要动的是归档输出链路：路径可达性、磁盘空间、FRA 使用率、ASM 磁盘组
USABLE_FILE_MB
修复 ARCH 卡死的实操步骤（按优先级顺序）
从最常见诱因开始排查，每步做完都验证 ARCH 是否恢复活动：
- 查闪回区是否爆满：运行
SELECT NAME, SPACE_USED/SPACE_LIMIT*100 PCT_USED FROM V$RECOVERY_FILE_DEST;，若 >95%，立刻清理：RMAN TARGET /连接后执行DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-1';（注意别删掉备库还没收的日志） - 确认归档目标路径可写：在主库执行
HOST ls -ld <code>log_archive_dest_2，检查属主是否为oracle:oinstall、权限是否为drwxr-xr-x；若路径是 ASM（如+ARCHDG），查SELECT NAME, USABLE_FILE_MB FROM V$ASM_DISKGROUP WHERE NAME = 'ARCHDG';，USABLE_FILE_MB = 0表示某个 failgroup 写失败，需扩容或 rebalance - 临时切换归档目标绕过故障路径：执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;，再ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='LOCATION=/tmp/arch' SCOPE=BOTH;，然后ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;；成功后切回原路径并清理临时目录 - 强制归档切换验证通路：执行
ALTER SYSTEM ARCHIVE LOG CURRENT;，立刻查V$ARCHIVED_LOG看最新日志是否生成且DEST_ID = 2，再查备库 alert 日志是否出现RFS[?]: Archived Log Added
修复后必须验证的三个点
ARCH 恢复发送不等于 DG 同步自动跟上，以下三件事漏掉任一，备库可能继续积压或报错：
- 检查备库
V$ARCHIVE_GAP是否为空：若仍有 gap，说明卡死期间的归档没传全，需人工补传或用FAL_SERVER触发拉取 - 确认备库
MRP0进程已启动：执行SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';，状态应为APPLYING_LOG，否则需手动ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 盯 5 分钟备库 alert 日志：重点看是否有
Media Recovery Waiting for thread 1 sequence后面的序号是否持续递增，而不是卡在某一个数字不动
ARCH 卡死表象简单，但根因分散在存储、权限、ASM、FRA 四个层面；修完别急着走，一定要盯着备库日志里 sequence 号跑起来才算真正闭环。
