BACKUP RECOVERY AREA 不是备份FRA，而是将FRA中当前有效的备份片和归档日志复制到指定位置，不释放FRA空间；真正释放空间需用DELETE OBSOLETE、DELETE EXPIRED或DELETE ARCHIVELOG等清理命令。
为什么 BACKUP RECOVERY AREA 不是常规备份命令
这条命令根本不是用来“备份 fra”的，它只是把 fra 里**当前还有效、未过期的备份片（backup pieces）和归档日志**，再拷贝一份到指定位置（比如磁带或另一个磁盘路径）。它不清理、不压缩、不重组织，更不会帮你腾出 fra 空间。
常见错误现象：RMAN-06207: WARNING: 1289 objects could not be deleted 或 ORA-19809: limit exceeded for recovery files，说明你误以为执行了这个命令就能释放空间，结果 FRA 还是满的。
- 它只读取 FRA 中
LIST BACKUP和LIST ARCHIVELOG显示为 AVAILABLE 的文件 - 不会备份控制文件自动备份（
autobackup）或闪回日志（flashback logs） - 目标路径必须提前存在且有写权限，RMAN 不会自动创建目录
- 执行完后，FRA 原有文件一个不少，空间占用毫无变化
真正释放 FRA 空间的三个可靠操作
FRA 空间释放靠的是 RMAN 的保留策略（retention policy）+ 实际清理动作，不是靠“备份出去”。
-
DELETE OBSOLETE：按CONFIGURE RETENTION POLICY判定哪些备份已过期（比如RECOVERY WINDOW OF 7 DAYS），然后删除它们 —— 这是最常用也最安全的释放方式 -
DELETE EXPIRED：只清理控制文件/恢复目录里记录已丢失的备份条目（比如手动删了磁盘文件但没用 RMAN 删除），不碰真实文件，也不释放空间 -
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-3'：精准清理指定时间前已应用完的归档日志，适合归档暴增场景；注意加COMPLETED避免误删未应用的日志
执行前务必确认：SHOW RETENTION POLICY 和 LIST EXPIRED BACKUP，别在生产库上直接 DELETE FORCE。
BACKUP RECOVERY AREA 的实际适用场景
它只在一个窄场景下有用：需要把当前 FRA 里的全部可用备份集 + 归档日志，离线保存一份（比如迁移到磁带库、做异地归档），且你明确知道这些文件后续还会被 RMAN 管理（即不打算从 FRA 删除）。
- 目标设备必须挂载为 OS 路径，不能是 ASM diskgroup（RMAN 不支持直接写 ASM）
- 命令格式是
BACKUP RECOVERY AREA FORMAT '/nfs/backup/%U'，%U必须出现，否则报错RMAN-06172: no autobackup found - 如果 FRA 里有大量小归档日志，该命令会生成海量小文件，影响目标文件系统性能
- 不推荐用于日常运维，更适合一次性归档任务；日常备份请用
BACKUP DATABASE PLUS ARCHIVELOG
监控与预防 FRA 满溢的关键点
FRA 满导致实例挂起（ORA-19815）往往发生在归档高峰或备份失败后无人处理。光靠命令不够，得盯住源头。
- 查实时使用：
SELECT * FROM V$RECOVERY_FILE_DEST，重点关注SPACE_LIMIT - SPACE_USED差值，不是百分比 - 查谁占大头：
SELECT * FROM V$RECOVERY_AREA_USAGE，ARCHIVED LOG和BACKUP PIECE占比高就分别查归档生成速率和备份是否卡住 - 归档暴增时，优先检查
V$ARCHIVED_LOG的DEST_ID和DELETED字段，确认归档是否真被备份脚本调用DELETE INPUT -
DB_RECOVERY_FILE_DEST_SIZE别设太大（比如 2TB），FRA 不是垃圾桶，应配合备份频率反推合理值（例如每天全备 + 归档 100GB，保留 3 天 → 400GB 足够）
最常被忽略的是：归档日志被备份后，没加 DELETE INPUT，或者备份脚本本身失败却没告警 —— FRA 空间问题，90% 出在流程断点，不在命令本身。
