ORA-19606是RMAN因保护快照控制文件（snapcf_*.f）而主动拒绝删除操作，因其被设计为只读静态视图；RMAN-06091则因未分配维护通道导致delete obsolete无法执行，二者均非权限或磁盘空间问题，需分别通过临时切换快照路径并清理元数据、或显式分配maintenance channel来解决。
ORA-19606 和 RMAN-06091 是 delete obsolete 失败最常撞上的两个硬性拦路虎，不是权限问题，也不是磁盘满——而是 RMAN 的元数据保护机制或通道配置缺失在起作用。
ORA-19606：RMAN 主动拒绝删快照控制文件
这个报错本质是 RMAN 的“自我防护”：它把 snapcf_*.f 当作只读快照，禁止任何写入或覆盖操作。当你执行 delete obsolete，RMAN 扫描到某个 Control File Copy 的路径恰好等于当前 CONFIGURE SNAPSHOT CONTROLFILE NAME 的值（比如 /u01/app/oracle/dbs/snapcf_cdb.f），就会立刻中止并抛出 ORA-19606。
- 它不是权限/占用/磁盘满导致的，
show all查出的路径才是真实生效路径，别信文档默认值 - 老版本（如 11.2）不支持
show snapshot controlfile name，必须用show all - 修复核心是“临时绕开”：先改配置指向一个新路径（如
/tmp/snapcf_temp.f），再在 OS 层删/重命名原文件，然后用crosscheck controlfilecopy+delete expired controlfilecopy清理元数据残留 - 最后可选恢复原配置：
CONFIGURE SNAPSHOT CONTROLFILE NAME CLEAR或显式设回原路径
RMAN-06091：没分配维护通道就执行 delete
这个错误直白说就是“RMAN 不知道该用哪个设备去删”，尤其在多设备环境（DISK + SBT_TAPE 混用）下高频出现。它和备份时的通道无关，专指维护类命令（delete、crosscheck）所需的专用通道。
- 如果你在
RUN块外直接运行delete obsolete，且没提前CONFIGURE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK，就会触发此错 - 检查方式很简单：
list backup能看到备份集，但delete obsolete报 RMAN-06091，基本可锁定通道问题 - 临时解法：在
RUN块里显式分配，例如：RMAN> RUN {<br> ALLOCATE CHANNEL ch1 FOR MAINTENANCE DEVICE TYPE DISK;<br> DELETE NOPROMPT OBSOLETE;<br>} - 长期建议：用
CONFIGURE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK设为默认，避免每次手动配
为什么 delete obsolete 看似执行了却没释放空间？
这不是报错，但更隐蔽——命令跑完 LIST BACKUP 还有大量旧备份，df -h 磁盘也没变化。根本原因是 RMAN 元数据与物理文件状态脱节。
- 归档中断、FRA 满导致控制文件没及时记录新归档，retention policy 判定逻辑失效
- 有人用
rm手动删过备份文件，但没做crosscheck backup，RMAN 还以为那些文件存在 - 用了恢复目录（catalog），但执行时没连 catalog（
rman target / catalog user/pwd@catdb），RMAN 只读控制文件，策略可能滞后 - 务必前置三步：
SHOW RETENTION POLICY→REPORT OBSOLETE（预览）→CROSSCHECK BACKUP（同步状态）
真正难处理的永远不是单个报错，而是多个条件叠加：比如归档目录已满（触发数据库挂起），你急着跑 delete obsolete，结果先撞上 ORA-19606，绕过去后又因没连 catalog 导致清理不全——这时候得一层层剥开，先解决空间燃眉之急（CROSSCHECK ARCHIVELOG ALL + DELETE NOPROMPT EXPIRED ARCHIVELOG ALL），再回头修 RMAN 元数据一致性。
