Oracle 19c中FRA是RMAN备份、归档管理及FLASHBACK DATABASE的硬性依赖，必须显式配置DB_RECOVERY_FILE_DEST和DB_RECOVERY_FILE_DEST_SIZE（顺序无关），且数据库须处于ARCHIVELOG模式；未配置或配置错误将导致ORA-38729、ORA-19809等错误。
快速恢复区（FRA）必须显式配置，否则 RMAN 不会自动使用它；即使启用了 DB_RECOVERY_FILE_DEST，若大小为 0 或未设路径，RMAN 仍会报错或退回到默认位置。
确认数据库已启用 ARCHIVELOG 模式
快速恢复区依赖归档日志持续写入，NOARCHIVELOG 模式下无法启用 FRA。执行以下检查：
SQL> archive log list;
输出中必须包含 Database log mode: Archive Mode。若为 No Archive Mode，需先重启数据库并切换：
- 关闭数据库：
shutdown immediate - 启动到 mount 状态：
startup mount - 启用归档：
alter database archivelog; - 打开数据库：
alter database open;
设置 FRA 路径与大小（两个参数缺一不可）
DB_RECOVERY_FILE_DEST 和 DB_RECOVERY_FILE_DEST_SIZE 必须同时设置，且顺序无关。常见错误是只设路径、不设大小，导致 RMAN 报 ORA-19802: cannot use DB_RECOVERY_FILE_DEST without DB_RECOVERY_FILE_DEST_SIZE。
在 SQL*Plus 中执行：
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/app/oracle/fast_recovery_area' SCOPE=BOTH;<br>ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=4G SCOPE=BOTH;
注意：
- 路径需存在且 Oracle 进程有读写权限，否则启动时会报
ORA-19809 - 大小单位支持
K、M、G、T，但不能用GB或GiB -
SCOPE=BOTH确保立即生效且写入 spfile，避免重启后丢失
RMAN 自动识别 FRA 后的行为验证
配置完成后，RMAN 默认将备份集、归档日志、控制文件自动副本、闪回日志等写入 FRA，无需额外指定 FORMAT。验证方式：
进入 RMAN：rman target /，然后运行：
RMAN> SHOW ALL;
检查输出中是否含：
CONFIGURE CONTROLFILE AUTOBACKUP ON;<br>CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;<br>CONFIGURE DEFAULT DEVICE TYPE TO DISK;
再执行一次简单备份：
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
成功后，查看 FRA 目录内容：
ls -l $ORACLE_BASE/fast_recovery_area/<DB_UNIQUE_NAME>/
应看到 archivelog/、backupset/、autobackup/ 等子目录 —— 若只有空目录或报权限错误，说明路径未生效或磁盘满。
FRA 空间耗尽的典型表现与应急处理
FRA 不是“无限空间”，空间不足时 RMAN 会直接失败，报错如 ORA-19809: limit exceeded for recovery files 或 RMAN-06059: expected archived log not found（因归档被自动删除腾空间）。这不是 bug，而是 FRA 的自动清理机制在起作用。
关键点：
- 自动清理基于保留策略（
CONFIGURE RETENTION POLICY），不是按时间，而是按“能否满足恢复窗口”判断 -
crosscheck archivelog all+delete expired archivelog不解决根本问题，只是清理元数据残留 - 临时扩容：可动态增大
DB_RECOVERY_FILE_DEST_SIZE，但需确保底层文件系统有足够空间 - 长期建议：监控
V$RECOVERY_FILE_DEST视图中的SPACE_LIMIT和SPACE_USED，设置告警阈值（如 >85%）
FRA 配置本身很简单，真正难的是容量规划和保留策略匹配业务 RPO/RTO —— 很多人配完就不管，直到某天备份突然失败，才发现归档被删光、无法做 PITR。
