增量备份必须先有0级备份，否则rman会自动补做；真正可控的增量链需显式执行backup incremental level 0 database plus archivelog delete input，之后level 1才只扫变更块。
增量备份必须先有 0 级备份，否则 RMAN 会自动补做
很多人以为“增量”就是直接跑 backup incremental level 1，结果发现第一次执行时耗时极长、IO 峰值飙升——这是因为 RMAN 没找到基线，自动回退成全量扫描做 0 级备份。
真正可控的增量链，必须显式执行一次 0 级作为起点。它和全库备份内容一致，但关键区别在于：只有 backup incremental level 0 才能被后续 1 级引用；普通 backup database 不计入增量链。
- 首次部署必须手动执行：
backup incremental level 0 database plus archivelog delete input - 0 级备份后，再运行
backup incremental level 1才真正只扫变更块 - 若误删了 0 级备份，RMAN 在下次 level 1 时仍会自动重建，但会导致窗口不可控、日志爆满
差异增量（default）比累积增量更常用，但恢复路径更长
RMAN 默认使用差异增量（differential），即每次 level 1 备份只包含“自上次任意 level 0 或 1 以来变更的块”。它备份量最小、速度最快，但恢复时需按时间顺序逐个应用所有中间 level 1 备份。
累积增量（cumulative）则始终基于最近一次 level 0，每次 level 1 都包含自该 0 级以来所有变更。虽然单次备份体积大、耗时长，但恢复只需 latest 0 级 + latest cumulative 1 级。
- 日常调度建议用默认差异模式：
backup incremental level 1 database - 如需缩短恢复时间（RTO），可改用：
backup incremental level 1 cumulative database - 两者不能混用在同一备份链中，否则 RMAN 无法识别依赖关系
必须启用块更改跟踪（BCT），否则增量≈全量
Oracle 10g+ 引入 BCT 后，增量才真正具备实用价值。未启用时，RMAN 每次都要全盘扫描数据文件判断哪些块变了，1TB 数据库做一次 level 1 可能比全备还慢。
BCT 文件本身很小（通常几十 MB），但能将增量扫描时间从小时级压到分钟级，尤其对变化率低的大库效果显著。
- 启用命令：
alter database enable block change tracking using file '/u01/bct.f' - 确认状态：
select status, filename from v$block_change_tracking，输出ENABLED才生效 - BCT 文件建议放在非核心 ASM 磁盘组或独立本地磁盘，避免与数据文件争 IO
- 禁用命令：
alter database disable block change tracking，仅在维护或调试时临时关闭
归档日志清理不及时，增量备份会失败
增量备份本身不依赖归档日志，但实际脚本几乎都带 plus archivelog delete input。一旦归档目录写满或权限异常，整个备份流程会在归档阶段卡死或报错 ORA-19504: failed to create file。
这不是备份逻辑问题，而是存储层资源枯竭。很多故障发生在周末无人值守时，归档持续生成却无清理机制。
- 务必配置归档清理策略，例如：
delete noprompt archivelog until time 'sysdate-7' - 在备份脚本末尾追加清理命令，不要依赖 RMAN retention policy 自动清理（它只管备份集，不管归档）
- 监控
v$recovery_file_dest中space_used/ space_limit比值，超 85% 就要告警
