rman备份挂起是因归档目录满导致数据库无法生成新归档，进而阻塞rman归档备份；需先释放空间（如crosscheck/delete归档或手动清理过期文件），再恢复备份流程。
rman 备份挂起不是备份本身卡住了，而是归档目录满了、数据库无法生成新归档，导致 rman 等待归档完成——必须先释放空间，再恢复备份流程。
为什么 RMAN backup 命令会 hang 住
Oracle 11g 在 ARCHIVELOG 模式下，RMAN 执行 backup database plus archivelog 或显式 backup archivelog all 时，会隐式触发归档切换（log switch）。如果归档目录（log_archive_dest_1 或 FRA）已满，数据库无法写入新归档，联机日志无法归档，进而阻塞 checkpoint 和 RMAN 的 archivelog 备份阶段。
典型表现是 RMAN 进程长时间停留在 starting backup at ... 后无响应，同时数据库 alert 日志里反复出现：
ORA-00257: archiver error. Connect internal only, until freed ARC0: Error 19504 Creating archive log file to '/oracle/app/archivelog/1_123456_999999999.dbf'
这不是 RMAN 配置或语法问题，是底层 I/O 被阻断。
- 检查归档路径空间：
df -h /oracle/app/archivelog或查 FRA：select name, round((space_used/space_limit)*100, 2) "pct_used" from v$recovery_file_dest; - 确认归档是否真正卡住：
archive log list中Archive destination显示UNDEFINED或DISABLED，或Log sequence长时间不增长 - 不要直接
shutdown abort—— 可能导致未归档的联机日志丢失，影响恢复点
RMAN 能删的归档必须先清掉
挂起状态下，RMAN 仍可连接（rman target /），但只能操作控制文件中“可见”的归档记录。这些记录受 control_file_record_keep_time 限制（默认 7 天），超期的物理文件它根本不知道存在。
执行以下命令顺序不可颠倒：
rman target / RMAN> CROSSCHECK ARCHIVELOG ALL; RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; RMAN> DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'; RMAN> DELETE NOPROMPT OBSOLETE;
-
CROSSCHECK是关键：强制扫描磁盘上所有归档文件，并比对控制文件状态；没被识别的文件会标为EXPIRED -
DELETE EXPIRED清理元数据残留，避免后续LIST ARCHIVELOG显示脏数据 - 用
COMPLETED BEFORE而非UNTIL TIME：前者基于COMPLETION_TIME（真正写完时间），更准；后者查FIRST_TIME（开始归档时间），在高并发日志切换时易误判 - 备库上执行前，务必确认：
SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2;，确保不删未应用归档
手动清理 RMAN “看不见”的历史归档文件
上面 RMAN 命令通常只释放几百 MB 到几 GB，而真正占满磁盘的，往往是 30 天前的 *.dbf 文件——它们早被控制文件元数据覆盖，RMAN LIST ARCHIVELOG ALL 根本不显示。
进入归档目录后分两步操作：
- 先预览（别手抖）：
find /oracle/app/archivelog -name "*.dbf" -mtime +15 -ls | head -20，确认路径、文件名格式、时间戳是否符合预期 - 再删除：
find /oracle/app/archivelog -name "*.dbf" -mtime +15 -delete - 注意：
-mtime +15表示“修改时间超过 15 天”，对应业务保留策略（如备份要求保留 14 天）；若用-atime或-ctime不可靠，因访问/状态变更可能被监控脚本频繁触发 - 删除前务必确认：这些文件不在任何 RMAN 备份集中（
list backup of archivelog all;），且数据库运行稳定、无 PITR 计划
Data Guard 备库上清理要额外加锁和校验
主库清理后，备库可能因 MRP 进程延迟或 GAP 导致归档堆积，但直接删风险极高。不能复用主库脚本。
安全清理逻辑必须包含三重守门：
- 检查 GAP：
SELECT * FROM v$archive_gap;，非空则立即停止 - 确认 MRP 正在运行：
SELECT process, status FROM v$managed_standby WHERE process = 'MRP0';，状态必须是APPLYING_LOG - 只删已应用且超期的归档：
SELECT NAME FROM v$archived_log WHERE applied = 'YES' AND COMPLETION_TIME ，再对结果中的 <code>NAME路径执行rm -f - 切勿配置
configure archivelog deletion policy to applied on standby—— 该策略在 11g 备库上实际无效，且依赖重启和隐含参数，容易埋雷
最常被忽略的是：RMAN 删除动作本身不释放文件系统空间，只有 find ... -delete 或 rm -f 才真正回收 inode；而一旦删错未应用归档，DG 同步将永久中断，重建备库成本远高于停机十分钟手动清理。
