Default Device Type决定RMAN备份路径，若配置错误（如设SBT但未装MML）则备份无法启动，导致保留策略失效；DISK设备下BACKUP TYPE和PARALLELISM影响冗余计数逻辑，CONTROLFILE AUTOBACKUP路径缺失或ARCHIVELOG DELETION POLICY未绑定均使RETENTION POLICY形同虚设。
Default Device Type决定RMAN往哪写，不配错就根本走不到保留策略那步
oracle 19c中configure default device type to disk或to sbt不是“选个偏好”，而是底层i/o路径的开关。rman所有备份命令（比如backup database）默认都走这个设备类型；如果设成sbt但没装介质管理库（mml），备份会直接卡在分配通道阶段，连备份片都生成不了——自然也就没有元数据供retention policy判断是否obsolete。
常见错误现象：RMAN-00554: initialization of internal recovery manager package failed 或 RMAN-06003: ORA-12154: TNS:could not resolve the connect identifier（其实是MML加载失败，但报错不直观）。
- 查当前设置用：
SHOW DEFAULT DEVICE TYPE，别只信SHOW ALL里混着的其他配置 - 磁盘备份必须确保路径可写且空间足够，否则
BACKUP中途失败，控制文件里记了半截元数据，后续CROSSCHECK会把它标为EXPIRED而非OBSOLETE - 若用ASM，
FORMAT必须写成'+DG_NAME'这种格式，写成/u01/...会导致通道分配失败
DEVICE TYPE DISK的BACKUP TYPE和PARALLELISM直接影响RETENTION POLICY的计算粒度
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET和TO COPY看似只是存档格式差异，实则改变RMAN对“一份备份”的定义——而RETENTION POLICY里的REDUNDANCY 2是按“每个数据文件有几份有效BACKUPSET”计数的，IMAGE COPY不参与该计数。
并行度PARALLELISM更隐蔽：设成3后，一次BACKUP DATABASE可能生成3个独立备份集（每个通道一个），RMAN会把它们视为3份独立备份。若策略是REDUNDANCY 1，下次全备时旧的3份全被标为OBSOLETE——但实际你可能只想留最近一次全备，而不是最近三次。
-
BACKUP TYPE TO COMPRESSED BACKUPSET压缩率影响备份集大小，但不影响RETENTION POLICY逻辑；不过压缩失败会导致备份集不完整，REPORT OBSOLETE可能漏判 - 升级到19c后，
PARALLELISM默认仍是1，但很多DBA会手动调高；务必确认SHOW DEVICE TYPE DISK输出里的PARALLELISM值，不是看SHOW ALL里孤立的CONFIGURE语句 -
IMAGE COPY不能用于增量备份基础，所以RECOVERY WINDOW策略下它几乎不会被判定为OBSOLETE——因为缺少对应归档日志链，RMAN不敢删
CONTROLFILE AUTOBACKUP FORMAT路径失效，RETENTION POLICY直接失能
19c默认开启CONFIGURE CONTROLFILE AUTOBACKUP ON，但若没显式配置FORMAT，它会fallback到$ORACLE_BASE/fast_recovery_area。一旦FRA未初始化、权限不对或空间满（ORA-19809），控制文件自动备份静默失败——而RMAN的RETENTION POLICY依赖控制文件里记录的备份元数据做时间推算。元数据缺失，REPORT OBSOLETE结果就是空，DELETE OBSOLETE什么也不干。
- 必须执行：
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/path/to/backup/cf_%F.ctl'，%F是19c强制要求的占位符，别用%U - 验证是否生效：
LIST BACKUP OF CONTROLFILE，看输出路径是否匹配你配置的FORMAT - 如果FRA已启用，先查
V$RECOVERY_FILE_DEST确认SPACE_LIMIT和SPACE_USED，避免ORA-19809掩盖真正的路径配置问题
ARCHIVELOG DELETION POLICY不绑定，RECOVERY WINDOW策略形同虚设
RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS要生效，必须能完整追溯过去7天的归档日志链。但19c默认CONFIGURE ARCHIVELOG DELETION POLICY TO NONE，意味着RMAN删归档时只认LOG_ARCHIVE_DEST_n里标记为SYNC或STANDBY的目的地。如果你只用本地磁盘归档（LOCATION=/arch），DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'会跳过这些文件，导致归档堆积，最终撑爆FRA或备份目录。
- 正确绑定：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY（有备库）或TO BACKED UP 1 TIMES TO DISK（仅本地磁盘） - 检查当前策略：
SHOW ARCHIVELOG DELETION POLICY，不是SHOW ALL - 升级后必须重配——11g的归档删除策略不会继承到19c，哪怕
LOG_ARCHIVE_DEST_1路径没变
真正麻烦的从来不是配错一行命令，而是几个配置项之间隐含的依赖关系：设备类型决定能否落盘，备份类型决定如何计数，控制文件路径决定元数据是否存在，归档策略决定恢复链是否完整。少一个，RETENTION POLICY就只剩个壳子。
