rman备份策略必须严格匹配rpo和rto：全量每周、增量每日、归档每小时；retention policy推荐设为7天恢复窗口；每次备份需执行crosscheck与delete obsolete清理。
备份类型和频率必须匹配业务恢复目标
RMAN 备份策略不是凭经验拍脑袋定的，核心依据是 RPO（恢复点目标）和 RTO（恢复时间目标）。比如业务允许最多丢失 1 小时数据，那归档日志就必须每小时备份一次；如果要求 2 小时内恢复，全量备份就不能只做每周一次——得看实际恢复耗时测试结果。
- 全量备份：建议每周日凌晨执行，保留 4 周。使用
BACKUP DATABASE+PLUS ARCHIVELOG DELETE INPUT，避免归档堆积 - 增量备份：每天一次级别 1 差异备份（
BACKUP INCREMENTAL LEVEL 1），不依赖上一次增量，恢复链更短 - 归档日志：每小时执行一次
BACKUP ARCHIVELOG ALL DELETE INPUT，确保恢复窗口连续 - 控制文件与 SPFILE：每次备份后自动触发
CONTROLFILE AUTOBACKUP ON，格式设为/u01/backup/rman/ctl_%F
RETENTION POLICY 不能只设冗余值
默认 CONFIGURE RETENTION POLICY TO REDUNDANCY 1 意味着只保留最新一份备份，但生产环境几乎没人这么用——它无法保证你一定能恢复到某时间点。真正可用的是基于恢复窗口的策略。
- 推荐配置：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS，RMAN 会自动标记并清理超出 7 天的过期备份 - 注意：这个策略生效的前提是归档日志没被提前删掉，否则恢复窗口会断开
- 慎用
CONFIGURE RETENTION POLICY TO NONE——闪回恢复区（FRA）可能迅速写满，触发ORA-19809错误导致数据库挂起
脚本里必须包含 crosscheck 和 delete obsolete
备份脚本跑得再勤，不清理元数据和物理残留，时间一长就会出现“备份存在但 RMAN 找不到”或“磁盘满了但 LIST BACKUP 显示空间充足”的诡异现象。
- 每次备份前加：
CROSSCHECK ARCHIVELOG ALL; DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; - 每次备份后加：
CROSSCHECK BACKUP; DELETE NOPROMPT EXPIRED BACKUP; DELETE NOPROMPT OBSOLETE; -
DELETE NOPROMPT OBSOLETE依赖当前RETENTION POLICY设置，不是简单删旧文件，而是按恢复能力判断是否可删 - 别省略
NOPROMPT——定时任务里卡在交互提示就等于备份失败
通道配置和压缩要结合存储性能调优
并行度不是越高越好，CONFIGURE DEVICE TYPE DISK PARALLELISM 4 在普通 SATA 盘上反而容易 I/O 争抢，而 NVMe 或 SAN 环境下不开并行又浪费带宽。
- 磁盘备份推荐：
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/backup/rman/%U' MAXPIECESIZE 2G;——避免单文件过大影响传输和校验 - 压缩选
BASIC足够，LOW或MEDIUM压缩算法在 Oracle 19c+ 才稳定支持，老版本用了可能报错 - 如果用 FRA（
DB_RECOVERY_FILE_DEST），确保其大小设为数据库容量的 1.5–2 倍，否则BACKUP PLUS ARCHIVELOG可能因空间不足中断
真正难的不是写对一条 BACKUP DATABASE 命令，而是让每次 RESTORE DATABASE 都能成功跑通——这意味着归档路径权限、控制文件快照一致性、备份集跨目录可移动性，全都得在脚本里显式处理，而不是依赖“应该没问题”。
