RMAN的BACKUP INCREMENTAL LEVEL 1 DATABASE默认为差异增量备份，仅捕获自最近一次任意级别备份以来修改的块，依赖有效归档模式、已存在LEVEL 0备份及启用块更改跟踪，且必须配合PLUS ARCHIVELOG DELETE INPUT执行。
直接说结论：rman 的 backup incremental level 1 database 默认就是差异（differential）增量备份，无需额外指定关键词；但必须确保已有 level 0 基准备份，且归档日志被正确纳入并清理，否则备份链会断裂、后续恢复失败。
为什么默认就是 DIFFERENTIAL，不是 CUMULATIVE？
RMAN 中 LEVEL 1 不带 CUMULATIVE 关键字时，行为固定为 Differential：它只捕获自**最近一次任意级别（LEVEL 0 或 LEVEL 1）备份以来修改过的数据块**。这个“最近一次”由控制文件中记录的检查点 SCN 自动判定，不可手动覆盖。
常见误解是认为“没写 CUMULATIVE 就不确定”，其实恰恰相反——不加 CUMULATIVE 才是明确启用 Differential 模式。加了 CUMULATIVE 反而变成另一种语义（自最近 LEVEL 0 以来所有变化），二者不能混用在同一备份周期内。
-
BACKUP INCREMENTAL LEVEL 1 DATABASE→ Differential（默认） -
BACKUP INCREMENTAL CUMULATIVE LEVEL 1 DATABASE→ Cumulative（显式声明） - 同一数据库中交替使用两者，会导致
LIST BACKUP输出难以追溯依赖关系，恢复时可能选错基准
执行前必须确认的三个硬性前提
缺一不可，否则 LEVEL 1 备份看似成功，实则无法用于恢复：
- 数据库已启用归档模式：
ARCHIVELOG，且LOG_ARCHIVE_DEST_1配置有效 - 已存在至少一个成功的
LEVEL 0备份（可通过LIST BACKUP OF DATABASE SUMMARY查看LEVEL列和COMPLETION TIME） - 块更改跟踪（BCT）已开启：
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/oradata/orcl/rman_bct.f'；否则 RMAN 会退回到全数据文件扫描，失去增量意义
实际执行时必须带上 PLUS ARCHIVELOG DELETE INPUT
只跑 BACKUP INCREMENTAL LEVEL 1 DATABASE 是危险操作——它不会自动删除已备份的归档日志，导致 FRA（DB_RECOVERY_FILE_DEST）迅速占满，后续 LEVEL 1 备份可能静默失败或触发自动清理旧备份（包括你的 LEVEL 0）。
正确写法（推荐放入脚本）：
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
BACKUP INCREMENTAL LEVEL 1 DATABASE
PLUS ARCHIVELOG DELETE INPUT
FORMAT '/backup/orcl/lev1_%U';
RELEASE CHANNEL c1;
}
-
PLUS ARCHIVELOG确保归档日志参与备份链 -
DELETE INPUT表示只要归档已被成功写入备份集，就立即从原位置删除 - 务必配
FORMAT显式指定路径，避免误写入 FRA 导致空间争用
最容易被忽略的验证动作：检查备份链完整性
RMAN 不会在 LIST BACKUP OF DATABASE 中直接标出“父备份 ID”，你得靠时间+级别交叉比对：
- 运行
LIST BACKUP OF DATABASE BY BACKUP，关注每条记录的LEVEL和COMPLETION TIME - 找一个
LEVEL 1记录，向上查：最近的、完成时间早于它的LEVEL 0或更早LEVEL 1是否存在？是否在保留策略内？ - 用
VALIDATE BACKUPSET <BS_KEY>抽样验证关键备份集是否可读（尤其LEVEL 0）
真正出问题往往不在备份当时，而在半年后做恢复演练时才发现某次 LEVEL 1 实际指向了一个已被自动清理的 LEVEL 0 —— 因为没设好 RETENTION POLICY 或 FRA 空间不足触发了非预期裁剪。
