RMAN升级至19c后必须显式配置controlfile autobackup路径、backup optimization、archivelog deletion policy及parallelism，否则备份可能静默失败或恢复链断裂。
rman 不需要重写脚本，但必须调整几个关键配置项，否则备份可能失败或无法用于恢复。
controlfile autobackup 格式必须显式指定
19c 默认启用 CONFIGURE CONTROLFILE AUTOBACKUP ON，但自动备份路径若未显式设置，会 fallback 到闪回区（$ORACLE_BASE/fast_recovery_area），而升级后新库的闪回区路径往往未初始化或权限不对，导致控制文件备份静默失败。
常见错误现象：RMAN-03009: failure of backup command on ORA_DISK_1 channel + ORA-19809: limit exceeded for recovery files
- 执行前先确认闪回区是否可用：
SELECT NAME, SPACE_LIMIT, SPACE_USED FROM V$RECOVERY_FILE_DEST; - 更稳妥的做法是强制指定磁盘路径：
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/applog/dumpfile2/rman_to_19c/cf_%F.ctl'; - 注意
%F是 19c 推荐的格式占位符（固定 19 字符，含时间戳和 DBID），不要用%U替代
backup optimization 在跨版本升级后默认失效
11g 的 RMAN 配置（如 CONFIGURE BACKUP OPTIMIZATION ON）在升级到 19c 后不会自动继承，且 19c 对“相同内容是否跳过备份”的判断逻辑更严格——尤其涉及压缩、加密、块变更跟踪（BCT）状态不一致时，容易误判为“不可跳过”，导致重复备份归档日志或全库。
使用场景：你沿用旧的 BACKUP DATABASE PLUS ARCHIVELOG 脚本，但发现归档备份量比升级前翻倍。
- 检查当前状态：
SHOW BACKUP OPTIMIZATION; - 如果原库依赖该优化，升级后需手动开启：
CONFIGURE BACKUP OPTIMIZATION ON; - 但前提是：确保
V$BLOCK_CHANGE_TRACKING.STATUS = 'ENABLED'，且 BCT 文件本身已从 11g 迁移或重建（11g 的 BCT 文件不能直接被 19c 读取）
archivelog deletion policy 必须重新绑定到新归档目标
11g 的归档路径（如 LOG_ARCHIVE_DEST_1='LOCATION=/arch'）在 19c 中仍可工作，但 RMAN 的删除策略（ARCHIVELOG DELETION POLICY）默认只认 LOG_ARCHIVE_DEST_n 中标记为 SYNC 或 STANDBY 的目的地。如果升级后只保留本地归档（LOCATION=+DG_ARCH），不显式配置策略，RMAN 执行 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 可能报错或漏删。
典型错误：RMAN-08137: WARNING: archived log not deleted, no valid checkpoint found
- 确认当前归档目的地类型：
SELECT DEST_NAME, STATUS, TARGET, BINDING FROM V$ARCHIVE_DEST WHERE DEST_NAME LIKE 'LOG_ARCHIVE_DEST%'; - 若仅用本地磁盘/ASM 归档，必须显式声明：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; -- 若无备库，改用：CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK; - 注意：该配置不继承自 11g，升级后为空，必须手工设置
parallelism 和 compressed backupset 需验证 I/O 与 CPU 匹配度
11g 备份脚本里常用 ALLOCATE CHANNEL c1 DEVICE TYPE DISK + BACKUP AS COMPRESSED BACKUPSET，但在 19c 中，压缩算法升级为 ZLIB（默认）或 LZ4（需显式指定），CPU 消耗显著上升；若并行通道数（PARALLELISM）照搬 11g 设置（比如 4），可能压垮旧服务器 CPU，反而拖慢整体备份速度。
性能影响：测试发现，同样 1TB 数据，11g 下 4 通道压缩备份耗时 3.6 小时；19c 下若未调优，可能升至 5+ 小时，且 v$session_longops 显示大量 backup & restore 等待事件。
- 先查当前配置：
SHOW DEVICE TYPE DISK;（看 PARALLELISM 和 BACKUP TYPE） - 建议起步值：
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; - 如需 LZ4 加速（要求 Oracle 19c RU 19.11+）：
BACKUP AS COMPRESSED BACKUPSET USING COMPRESSED WITH LEVEL 1 DATABASE;（注意 LEVEL 1 ≠ Level 1 增量，是 LZ4 压缩等级）
最易被忽略的是控制文件自动备份路径和归档删除策略——它们不报错，但会导致恢复链断裂；一旦发生故障，你以为有完整备份，实际缺关键控制文件或归档，根本无法前滚。
