19c升级后backup optimization默认关闭且不继承旧配置，需手动执行configure backup optimization on并验证状态；其生效依赖dbid、线程、序号、resetlogs scn及时间戳一致，且受归档路径变更、只读表空间、块变更跟踪和压缩算法影响。
必须手动开启，且默认不生效——19c 升级后原配置不会继承，configure backup optimization on 不是“一设就灵”，得配合状态检查和底层条件。
为什么开了 BACKUP OPTIMIZATION ON 还是重复备份归档日志
最常见原因：升级后该配置被重置为 OFF，而你没重新执行。RMAN 不会保留 11g 的配置项，哪怕脚本里写过，19c 启动 RMAN 后也得重配。
- 先确认当前状态：
SHOW BACKUP OPTIMIZATION;—— 输出不是ON就得马上配 - 执行启用：
CONFIGURE BACKUP OPTIMIZATION ON; - 但注意：仅此一条不够。如果归档日志路径变了（比如从
/arch换成+DG_ARCH），RMAN 会认为“新位置没备过”，照样全量备份 - 归档日志的等同性判断依赖
DBID、线程、序号、RESETLOGS SCN和时间戳，任意一项不匹配，优化就失效
BACKUP OPTIMIZATION 对只读表空间无效
它只判断“数据文件是否被修改过”，而只读表空间的文件头 SCN 停滞，RMAN 根本不把它纳入去重比对流程——所以即使内容完全没变，也会照常备份。
- 真想跳过，必须显式干预：
BACKUP DATABASE SKIP READONLY; - 或全局排除：
CONFIGURE EXCLUDE FOR TABLESPACE 'USERS_RO'; - 两者可共存，但
EXCLUDE优先级更高；SKIP READONLY是单次命令级，不影响其他备份 - 别信 RMAN 日志里一闪而过的 “skipping” 提示，查
V$BACKUP_DATAFILE或LIST BACKUPSET才算数
开启后必须验证压缩与块变更跟踪是否就绪
BACKUP OPTIMIZATION 在 19c 中对“相同内容”的判定更严格，尤其涉及压缩、加密或块变更跟踪（BCT）状态时，容易误判为“不可跳过”。
- 检查 BCT 是否启用：
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 '/path/to/new_bct.f'; - 如果用了压缩备份（
AS COMPRESSED BACKUPSET），还得确认：CONFIGURE COMPRESSION ALGORITHM 'BASIC';—— 其他算法如HIGH在磁盘上静默失效 - 验证是否真跳过：跑一次
BACKUP ARCHIVELOG ALL后，查V$RMAN_BACKUP_JOB_DETAILS，对比INPUT_BYTES_DISPLAY和OUTPUT_BYTES_DISPLAY，再看COMPRESSION_RATIO是否 > 1.0
最容易被忽略的是归档日志删除策略未同步更新——ARCHIVELOG DELETION POLICY 默认只认 SYNC 或 STANDBY 类型的归档目标，如果升级后只剩本地 LOCATION，RMAN 可能拒绝删除旧归档，间接导致优化失效（因为“已备份”状态无法闭环）。
