RMAN-08137报错本质是归档删除策略与DG物理状态不匹配，非RMAN故障；常见因备库延迟、SYNC路径卡住或19c升级后未重配DELETION POLICY（默认TO NONE）；须显式执行CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY，并校验SHOW ALL输出；FORCE删除可应急但破坏DG保护，需人工处理GAP。
RMAN-08137报错本质是策略与物理状态不匹配
不是rman坏了，而是它在严格执行你配置的归档删除策略。当你在dg环境里执行delete archivelog却收到rman-08137: archived log not deleted, needed for standby or upstream capture process，说明rman查到：你要删的归档，在备库上还没应用（applied on standby）或没传完（shipped to all standby）。它宁可不删，也不破坏dg恢复链。
常见诱因包括：
- 备库延迟严重，
v$archived_log.applied = 'NO'的归档积压太多 - 主库
LOG_ARCHIVE_DEST_n中某条路径配置了SYNC但网络/备库IO卡住，导致RMAN认为“尚未传完” - 升级19c后未重配
ARCHIVELOG DELETION POLICY，仍沿用默认TO NONE，但脚本里又硬写了BACKED UP 2 TIMES——策略和命令逻辑冲突
CONFIGURE ARCHIVELOG DELETION POLICY必须显式设置
19c不会继承11g的策略配置，且默认是TO NONE。如果你依赖DG场景下的安全删除，必须手动执行：
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
注意三点：
-
APPLIED ON ALL STANDBY比APPLIED ON STANDBY更严格——要求所有备库都已应用，不只是其中一个 - 配置后立即生效，无需重启实例，但
SHOW ALL要确认输出里确实是APPLIED ON ALL STANDBY，不是APPLIED ON STANDBY（少ALL会漏判） - 若用
SHIPPED TO ALL STANDBY，需确保所有LOG_ARCHIVE_DEST_n都设为VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)且网络通畅，否则RMAN无法确认“是否真已 shipped”
FORCE不是万能解，但它是紧急空间释放的唯一手段
当FRA爆满、节点hang住、业务中断时，DELETE NOPROMPT FORCE ARCHIVELOG是快速腾空间的实操动作：
DELETE NOPROMPT FORCE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE - 7';
但它带来两个后果：
- 触发
RMAN-08591: WARNING: invalid archived log deletion policy——因为FORCE绕过了策略校验，RMAN会警告你“当前策略失效”，但操作本身成功 - 删掉的归档如果备库还没应用，会导致备库GAP，必须人工介入：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;再观察v$archive_gap - 不能常态化使用：它不检查DG状态，只认时间条件，长期开
FORCE等于放弃DG保护能力
跨版本升级后最容易被忽略的三件事
从11g升到19c，光改ARCHIVELOG DELETION POLICY不够，以下三项不补全，策略照样静默失效：
-
CONTROLFILE AUTOBACKUP FORMAT必须显式指定磁盘路径，否则自动备份写进FRA，而新库FRA常未初始化，控制文件备份失败 → RMAN元数据丢失 → 归档策略无依据 -
BACKUP OPTIMIZATION默认关闭，若旧脚本依赖它跳过重复归档备份，升级后会反复备份同一段归档，撑爆FRA -
V$BLOCK_CHANGE_TRACKING.STATUS必须为'ENABLED'且BCT文件已重建（11g的BCT文件19c不兼容），否则BACKUP OPTIMIZATION判断失准，归档备份量翻倍
真正麻烦的从来不是命令怎么敲，而是控制文件里记的归档状态、备库实际应用进度、RMAN策略配置这三者之间差了半拍——差这一拍，DELETE就变成NOT DELETED。
