升级至19c后RMAN不继承11g配置，须手动重设CONTROLFILE AUTOBACKUP FORMAT、BACKUP OPTIMIZATION、BLOCK CHANGE TRACKING、ARCHIVELOG DELETION POLICY及RETENTION POLICY，否则备份静默失败或恢复链断裂。
升级后rman不会自动继承11g的配置，必须手动重设几个关键参数，否则备份可能静默失败、归档重复备份、或恢复链断裂。
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT必须显式指定
19c默认开启CONTROLFILE AUTOBACKUP，但若未用CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ...指定路径，会fallback到闪回区（$ORACLE_BASE/fast_recovery_area）。而新库的FRA往往未初始化或权限不对，导致控制文件备份无声失败——后续RESTORE CONTROLFILE直接报RMAN-03002或ORA-19809。
- 先查FRA是否可用：
SELECT NAME, SPACE_LIMIT, SPACE_USED FROM V$RECOVERY_FILE_DEST; - 更稳妥做法是强制指向可写磁盘路径：
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/rman/cf_%F.ctl'; - 务必用
%F（19字符固定格式，含DBID+时间戳），不要用%U替代
CONFIGURE BACKUP OPTIMIZATION ON需手动开启并验证依赖
11g的BACKUP OPTIMIZATION配置在19c中完全丢失，默认为OFF。即使你脚本里写过，19c启动RMAN后也得重配。开了也不一定生效——它依赖多个底层状态一致。
- 先确认：
SHOW BACKUP OPTIMIZATION;输出不是ON就得立即执行CONFIGURE BACKUP OPTIMIZATION ON; - 检查块变更跟踪是否就绪：
SELECT STATUS FROM V$BLOCK_CHANGE_TRACKING;必须是ENABLED；11g的BCT文件19c不兼容，需重建：ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/new/path/bct.f'; - 归档路径变更会导致优化失效：若源库归档在
/arch，目标库改用ASM（+DG_ARCH），RMAN会认为“新位置没备过”，照样全量备份归档日志 - 只读表空间不受优化影响，必须显式跳过：
BACKUP DATABASE SKIP READONLY;或CONFIGURE EXCLUDE FOR TABLESPACE 'USERS_RO';
ARCHIVELOG DELETION POLICY必须绑定到实际归档目标
19c的DELETE ARCHIVELOG命令默认只信任LOG_ARCHIVE_DEST_n中BINDING=SYNC或STANDBY类型的目的地。如果升级后只保留本地归档（LOCATION=+DG_ARCH），不显式配置策略，DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'可能报RMAN-08137或漏删。
- 查当前归档目的地类型：
SELECT DEST_NAME, TARGET, BINDING FROM V$ARCHIVE_DEST WHERE STATUS = 'VALID'; - 若仅用本地归档，需显式绑定删除策略：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;不适用？那就用更直白的方式：CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;然后靠人工或脚本清理，避免误删 - 注意：该策略与
RETENTION POLICY无关，是独立配置项
RETENTION POLICY需按RPO选型且补全三步动作
RETENTION POLICY只是定义“什么算过期”，不自动清理。配错或漏步骤，轻则FRA爆满（ORA-19809），重则删掉唯一可用备份。
- 二选一：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;（按时间点恢复能力）或CONFIGURE RETENTION POLICY TO REDUNDANCY 2;（按份数），不能共存 - 配完必须补三步：
CROSSCHECK BACKUP;→REPORT OBSOLETE;→ 人工核对后再执行DELETE OBSOLETE; - 若归档日志链不完整（比如中间被
DELETE ARCHIVELOG清过），RECOVERY WINDOW会静默降级，REPORT OBSOLETE显示的过期备份比预期少，且不报错
最容易被忽略的是：这些配置都写在控制文件里，而控制文件本身若因AUTOBACKUP路径未设导致从未成功备份过，整个RMAN元数据链就断了——某天真正需要恢复时，连最新的控制文件都找不回来。
