ora-19815报错是因控制文件未同步归档日志删除状态，需用rman执行crosscheck archivelog all和delete expired更新元数据，否则v$flash_recovery_area_usage统计不释放。
ora-19815 不是磁盘真满了，而是 oracle 认为 fra 满了——直接 rm 归档日志没用，必须用 rman 同步元数据才能释放空间。
为什么删了归档日志还是报 ORA-19815
Oracle 的快速恢复区（FRA）由控制文件统一跟踪文件状态。你在 OS 层用 rm 删除归档日志后，物理文件确实没了，但控制文件里仍记录着这些文件存在，v$flash_recovery_area_usage 统计值不会变，空间“未被释放”。数据库启动或归档时仍会检查该元数据，于是持续报错。
-
v$archived_log中对应日志的deleted列仍是NO，status可能为EXPIRED或A（但实际文件已不存在） -
SELECT * FROM v$flash_recovery_area_usage;显示archived log的percent_space_used仍为 100% -
show parameter db_recovery_file_dest_size查到的限额远小于df -h显示的磁盘剩余空间
RMAN 清理必须执行 CROSSCHECK + DELETE EXPIRED
仅运行 DELETE ARCHIVELOG ALL 可能失败或不生效；必须先让 RMAN 扫描物理路径、更新元数据，再清理“过期”记录。
- 连接 RMAN：
rman target / - 强制校验归档日志物理存在性：
CROSSCHECK ARCHIVELOG ALL; - 删除元数据中已失效的条目：
DELETE EXPIRED ARCHIVELOG ALL; - 如需进一步释放空间，可加
DELETE OBSOLETE;（依赖当前 RMAN 保留策略）
执行后立刻查 v$flash_recovery_area_usage，percent_space_reclaimable 会上升，说明空间已被 Oracle 识别为可回收。
扩容 db_recovery_file_dest_size 是临时解法，但要慎用
增大 db_recovery_file_dest_size 能让数据库继续归档，但它不解决根本问题——如果归档生成速度 > 清理速度，很快又会满。仅建议在紧急恢复服务时配合 RMAN 清理一起用。
- 动态修改（无需重启）：
ALTER SYSTEM SET db_recovery_file_dest_size = 100G SCOPE=BOTH; - 确认生效：
SHOW PARAMETER db_recovery_file_dest_size; - 注意：该参数只是逻辑上限，不能超过底层文件系统真实可用空间
- 长期应调整 RMAN 策略，例如：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;（Data Guard 环境）
备库上处理 ORA-19815 要额外确认 MRP 状态
备库 FRA 满，大概率不是归档太多，而是 MRP（Managed Recovery Process）卡住没应用，导致归档堆积。不能一删了之。
- 先查应用状态：
SELECT sequence#, applied FROM v$archived_log ORDER BY sequence# DESC FETCH FIRST 5 ROWS ONLY;—— 若applied = 'NO'且无 GAP，则 MRP 可能停了 - 重启 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; - 再查
v$archive_gap和v$archive_dest_status，排除主库传输中断或路径权限问题 - 确认 MRP 运行中，再执行 RMAN 清理，否则刚清完又堆满
最易被忽略的是：RMAN 的 CROSSCHECK 必须在目标数据库 MOUNT 或 OPEN 状态下执行；若数据库因 ORA-19815 卡在 NOMOUNT，得先用 STARTUP MOUNT 进去再操作——否则 RMAN 连不上控制文件，所有清理都无效。
