rman备份挂起主因是归档目录空间耗尽导致日志无法切换，进而阻塞lgwr和检查点；rman无法删除超期归档因control_file_record_keep_time默认仅保留约7天元数据，须先crosscheck+delete expired清理可见部分，再手动删除物理残留。
rman 备份挂起不是因为归档日志“太多”，而是因为归档目录空间耗尽后，数据库无法生成新归档，进而阻塞重做日志切换，最终使所有 dml 操作等待、备份卡在 backup database 的第一个数据文件读取阶段。
归档满 → 日志无法切换 → RMAN 无法推进
Oracle 在归档模式下，每次重做日志组写满后必须完成归档（即把 redo01.log 内容写成 1_12345_987654321.dbf）才能被覆盖。一旦归档目录（如 /oracle/app/archivelog）磁盘满，ARCH 进程写失败，该日志组永久处于 ACTIVE 或 UNARCHIVED 状态。
后果是：
- 后续事务产生的重做无法写入新日志组，
LGWR报错并挂起写操作 -
DBWn和CKPT被连锁阻塞，整个实例变慢甚至hang -
RMAN BACKUP启动后需读取数据文件并触发检查点，但检查点无法完成（因日志无法切换），备份进程就卡在WAITING FOR CHECKPOINT或类似状态
为什么 RMAN 自己删不掉暴增的旧归档？
归档暴增往往伴随大量历史文件堆积（比如几个月前的 *.dbf），而 RMAN 根本“看不见”它们——这不是命令写错，是 Oracle 控制文件的设计限制。
control_file_record_keep_time 默认为 7 天，超过该窗口的归档记录在控制文件中已被覆盖。RMAN 所有 DELETE ARCHIVELOG 命令都依赖控制文件元数据，对无记录的物理文件完全无效。
常见误操作包括：
- 直接跑
DELETE ARCHIVELOG ALL，结果df -h空间纹丝不动 - 用
LIST ARCHIVELOG ALL查不到那些旧文件，误以为已被清理 - 执行
DELETE OBSOLETE却没生效，因这些文件不在任何保留策略覆盖范围内
紧急恢复 RMAN 备份能力的两步实操
必须分先后顺序执行，跳过任一环节都可能引发 v$archived_log 状态混乱或 DG 同步中断：
第一步：让 RMAN 清掉它“看得见”的部分
- 以
oracle用户登录：rman target / -
CROSSCHECK ARCHIVELOG ALL—— 强制扫描磁盘，标记状态不一致的文件为EXPIRED -
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL—— 清理已失效的元数据条目 -
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-15'—— 删除最近 15 天内完成归档的有效文件（注意用COMPLETED BEFORE，别用UNTIL TIME）
第二步：手动清理 RMAN “看不见”的物理残留
- 进归档目录：
cd /oracle/app/archivelog - 先预览：
find . -name "*.dbf" -mtime +15 -ls | head -20（确认路径和时间合理） - 再执行：
find . -name "*.dbf" -mtime +15 -delete - 务必确认这些文件远超业务恢复窗口（如备份策略只要保留 14 天），且不在任何
LIST BACKUP OF ARCHIVELOG结果中
RMAN 挂起时最易被忽略的细节
真正卡住 RMAN 的，往往不是归档本身，而是它背后的状态一致性要求：RMAN 在启动备份前会隐式检查归档完整性，若发现 v$archived_log 中存在 STATUS = 'D' (DELETED) 但磁盘仍有同名文件，或存在大量 STATUS = 'A' (AVAILABLE) 但控制文件无记录的文件，它可能拒绝继续或进入不确定等待。
所以手工删文件后，一定补上 CROSSCHECK + DELETE EXPIRED；DG 环境下还必须确认备库 APPLIED = 'YES' 再删主库归档——这些不是可选步骤，是避免二次故障的刚性约束。
