ORA-19809/19804报错时RMAN不删归档的真正原因是其默认只清理EXPIRED或超出保留策略的日志；AVAILABLE且未过期的归档即使FRA已满也不会被自动删除，必须显式指定时间/SCN范围或先清理EXPIRED归档。
ORA-19809 和 ORA-19804 报错时，RMAN 删除过期归档不生效的真正原因
不是 delete archivelog all 不管用，而是 rman 默认只删「标记为 expired」或「超出保留策略」的日志；如果归档还在控制文件里注册、又没过期，哪怕 fra 已满，它也不会动——这是最常被忽略的逻辑断点。
- 先确认归档状态：
LIST ARCHIVELOG ALL看哪些是AVAILABLE（RMAN 不会主动删），哪些是EXPIRED（可直接CROSSCHECK ARCHIVELOG ALL+DELETE EXPIRED ARCHIVELOG ALL） - 强制清理所有已注册但物理不存在的归档：先
CROSSCHECK ARCHIVELOG ALL，再DELETE EXPIRED ARCHIVELOG ALL - 要删掉“还活着但其实该删”的归档，必须显式指定时间/SCN 范围，比如：
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-3'，别依赖ALL - 注意：
DELETE INPUT是在备份后删源归档，不是通用清理手段；没做备份就跑这个，等于啥也没删
修改 db_recovery_file_dest_size 后空间仍不释放？FRA 配额变更的生效边界
FRA 配额改大只是“允许写入上限”，不会自动腾出旧空间；已占满时，新配额对正在堆积的归档日志毫无缓解作用——得先清空间，再调参数。
- 查当前使用：
SELECT * FROM V$RECOVERY_FILE_DEST，重点看SPACE_LIMIT和SPACE_USED - 增大配额命令：
ALTER SYSTEM SET db_recovery_file_dest_size = 20G SCOPE=BOTH（单位必须带 G/B，不能只写数字） - 但注意：如果
db_recovery_file_dest指向的磁盘本身已满（比如 /u01/fra 所在文件系统只剩 200MB），调大db_recovery_file_dest_size完全无效 - Oracle 11g 及以后版本支持在线调整，但 10g 需重启实例才能生效
RMAN 中 KEEP FOREVER 归档导致 FRA 永远清不干净
一旦某段归档被 BACKUP ARCHIVELOG ... KEEP FOREVER 标记，RMAN 就永久豁免其清理逻辑——哪怕你设了 RECOVERY WINDOW OF 7 DAYS，它也岿然不动。
- 检查是否有这类“钉子户”：
LIST BACKUP OF ARCHIVELOG ALL，关注输出里的KEEP字段和对应STATUS - 若确认不再需要，用
CHANGE BACKUPSET <code>xxxNOKEEP 解除保护，再配合DELETE ARCHIVELOG清理 - 日常备份脚本里慎用
KEEP FOREVER；如需长期保留，建议复制到外部存储后，再用DELETE INPUT主动清除 FRA 内副本
归档生成速度远超清理节奏时，光靠 RMAN 删除不够
当应用批量导入、大量 DML 或主库压力突增时，归档每分钟生成几百 MB，而人工执行 RMAN 命令有延迟，FRA 很快再次打满——这时候得从源头控速或加自动化兜底。
- 临时降低归档频率：停用
ARCHIVE_LAG_TARGET（如果启用），避免因超时强制切归档 - 确认归档目标是否冗余：检查
LOG_ARCHIVE_DEST_n，禁用不必要的远程归档路径（如LOG_ARCHIVE_DEST_2指向 standby 却长期断连，会导致本地归档积压） - 部署定时清理任务：用 OS 脚本封装 RMAN 命令，例如每 15 分钟执行一次
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2'，并重定向日志便于排查失败 - 监控必须前置：在
V$FLASH_RECOVERY_AREA_USAGE上建告警，当PERCENT_SPACE_USED > 85就触发通知，别等ORA-19809报出来才反应
归档清理不是一锤子买卖，FRA 空间问题背后往往是备份策略、归档路径配置、监控响应三者脱节。尤其 KEEP FOREVER 和磁盘底层空间不足这两点，最容易被当成“RMAN 没删干净”反复折腾。
