数据库挂起是因FRA空间耗尽而非文件系统满，需查V$RECOVERY_FILE_DEST和V$FLASH_RECOVERY_AREA_USAGE确认真实使用率，ARCHIVED LOG占比超95%即危险。
数据库挂起不是归档目录“看起来满了”，而是 db_recovery_file_dest 内部空间耗尽，mrp 进程卡在 wait_for_gap 或反复报 unnamed 错误——此时单纯删物理文件或执行 delete archivelog all 很可能无效，甚至引发同步断裂。
确认 FRA 真实使用率，别信 df -h
备库挂起时，df -h 显示磁盘还有空间，但数据库就是不恢复。这是因为 Oracle 的快速恢复区（FRA）有独立配额，由 DB_RECOVERY_FILE_DEST_SIZE 控制，和文件系统层面的剩余空间无关。
- 必须查
V$RECOVERY_FILE_DEST：它返回SPACE_USED和SPACE_LIMIT，算出真实使用率 - 再查
V$FLASH_RECOVERY_AREA_USAGE，重点关注ARCHIVED LOG行的PERCENT_SPACE_USED—— 超过 95% 就危险 - 如果
PERCENT_SPACE_RECLAIMABLE很低（比如
DELETE FORCE ARCHIVELOG 是备库清理的必要参数
在备库上执行 RMAN 清理时，不加 FORCE 几乎等于白干。因为 MRP 进程正在读取某些归档日志，RMAN 默认会跳过它们，导致清理后空间毫无变化。
- 正确命令是：
DELETE FORCE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1' -
COMPLETED BEFORE看的是COMPLETION_TIME，比UNTIL TIME更可靠，避免误删正在应用的日志 - 执行前先做一次
ALTER SYSTEM ARCHIVE LOG CURRENT（主库），等 60 秒，确保最新归档已传到备库再清理 - 严禁在未确认
APPLIED = 'YES'的归档上直接删 —— 查V$ARCHIVED_LOG WHERE DEST_ID = 2 AND APPLIED = 'NO'，这些不能动
手工清理前，先验证归档连续性，否则补不了 GAP
RMAN 看不见的旧归档（比如控制文件里已无记录的 3 年前 .dbf 文件），只能用 find 手工删。但这步极危险：删错一个序列号，主备就断链，MRP 永远卡在 WAIT_FOR_GAP。
- 先对比主备最大归档序列：
主库执行：SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID = 1 GROUP BY THREAD#
备库执行：SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID = 2 GROUP BY THREAD#
差值 ≤ 3 才算安全，超 5 就得暂停清理、先补日志 - 手工删之前，进归档目录（如
/u01/fast_recovery_area/DBNAME/archivelog）跑预览：find . -name "*.dbf" -mtime +14 -ls，确认全是超期且不在当前备份集里的文件 - 删完立刻执行
CROSSCHECK ARCHIVELOG ALL，防止V$ARCHIVED_LOG视图残留脏状态
STANDBY_FILE_MANAGEMENT 必须为 AUTO，否则 UNNAMED 错误永不消失
即使 FRA 腾出空间、归档也连续，MRP 还卡在 UNNAMED？大概率是这个参数被设成了 MANUAL。Oracle 在备库创建数据文件时，若路径不匹配又没自动转换，就会生成 UNNAMED 占位符并死锁。
- 查当前值：
SHOW PARAMETER STANDBY_FILE_MANAGEMENT - 如果是
MANUAL，立刻改：ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT = AUTO SCOPE=BOTH - 改完不用重启，但要确保
DB_FILE_NAME_CONVERT配置正确（主备数据文件路径映射），否则AUTO也没用 - 这个参数一旦设错，后续所有空间清理都只是给错误让路，问题根源纹丝不动
最常被忽略的一点：FRA 满不只是归档日志的事，CONTROL FILE AUTOBACKUP、FLASHBACK LOG、甚至临时 BACKUP PIECE 都可能占大头。查 V$FLASH_RECOVERY_AREA_USAGE 时，别只盯着 ARCHIVED LOG 行——有时候删掉几个 2GB 的控制文件快照，比清一周归档还管用。
