Level 0备份是标记为增量链起点的全量物理备份，要求数据库处于ARCHIVELOG模式，不依赖前置备份，跳过空块且建议打tag；Level 1默认为差异型，只对比最近一次level 0或level 1，累积型则仅对比上一个level 0；备份链断裂主因是level 0缺失或被清理；归档日志对恢复必不可少。
Level 0备份就是全量基线，不是“伪全量”
level 0在rman里本质就是一次全量物理备份，但它和传统backup database的区别在于：它明确标记自己是增量链的起点，且会记录块变更跟踪（bct）所需的元数据。数据库不处于archivelog模式时，backup incremental level 0会直接报错，这点比普通全备更严格。
常见错误现象：RMAN-03002: failure of backup command at ... ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode —— 必须先确认select log_mode from v$database;返回ARCHIVELOG。
- Level 0不依赖任何前置备份，可单独用于恢复
- 它备份所有已使用数据块，跳过从未写入过的空块（这点比老式
cp冷备更省空间） - 建议打
tag，比如backup incremental level 0 database tag 'weekly_base'，避免后续混淆
Level 1默认是差异型，不是累积型
RMAN执行backup incremental level 1时，不加cumulative关键字，就是差异备份（differential）。它的“最近一次同级或更高级别备份”指的是：往上找第一个level 0或level 1备份，哪怕中间隔了三天、五个level 1，它也只管那个“最近”的。
举例：周一level 0 → 周二level 1（差异）→ 周三又执行level 1（差异），那么周三这次只备份周二到周三的变更块，不包含周一到周二的。
- 差异型备份体积小、速度快，适合日常高频执行
- 恢复时需按时间顺序应用：最近
level 0+ 所有后续差异level 1（从早到晚） - 误用
cumulative却不调整保留策略，容易导致磁盘爆满——因为累积备份体积接近level 0
累积型Level 1只认Level 0，无视中间所有Level 1
backup incremental level 1 cumulative的逻辑非常干净：它只看上一个level 0，不管中间有没有其他level 1。只要自那个level 0以来有变化，它就全包。
恢复优势明显：只需level 0 + 最新一次cumulative level 1，跳过中间所有备份。但代价是——周三的累积备份可能比周二的差异备份大5倍，尤其当数据库变更率高时。
- 适用场景：RTO极敏感、备份存储充足、且希望简化恢复脚本逻辑
- 不能混用
cumulative和differential在同一备份链中——RMAN不报错，但恢复路径会不可预测 - 检查当前备份类型：用
list backup of database summary;看INCR列，CUMULATIVE或DIFFERENTIAL会明确标出
增量备份链断裂的真实原因常被忽略
很多人以为“删掉旧level 1就断链”，其实真正致命的是删掉了level 0，或者level 0被retention policy自动清理但没及时补新基线。
典型表现：restore database preview;返回no backup of datafile found to restore，即使list backup能看到一堆level 1。
- 必须确保至少一个
level 0始终在保留窗口内（如配置了recovery window of 7 days，就得每周至少跑一次level 0） -
configure backup optimization on虽能跳过未变更文件，但对level 0无效——它永远强制全量 - 归档日志不是可选件：哪怕只做
level 1，没有对应时段的归档，recover database会卡在ORA-00279
