必须先确认数据库处于ARCHIVELOG模式、启用块更改跟踪、存在最近的LEVEL=0备份；三者缺一不可，否则增量备份效率低或恢复不可靠。
能用，但必须先确认数据库处于归档模式且开启了块更改跟踪（否则增量备份效率极低）。
增量备份前必须检查的三个状态
RMAN增量备份不是“开箱即用”，它依赖底层数据库配置。漏掉任一环节，BACKUP INCREMENTAL 命令可能成功执行，但实际备份量和恢复可靠性会出问题：
- 数据库必须运行在
ARCHIVELOG模式 —— 查看：SELECT log_mode FROM v$database;，返回ARCHIVELOG才合规 - 推荐启用块更改跟踪（BCT）：否则 RMAN 每次都要全扫描数据文件找变化块，100GB 数据库做 1 级增量可能比全备还慢。启用命令：
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/oradata/orcl/bct.f'; - 确认控制文件中记录的最近一次 0 级备份存在 —— RMAN 1 级增量默认基于上一次 0 级（全备），不是上次 1 级。查：
LIST BACKUP OF DATABASE SUMMARY;，看是否有LEVEL=0记录
区分 LEVEL=0 和 LEVEL=1 的真实含义
很多人误以为 LEVEL=1 是“自上次任意备份以来的变更”，其实 RMAN 的层级逻辑更严格：
-
BACKUP INCREMENTAL LEVEL 0 DATABASE：本质是全量备份（镜像级），但会打上LEVEL 0标签，作为后续 1 级的基线。它不依赖任何已有备份 -
BACKUP INCREMENTAL LEVEL 1 DATABASE：默认找最近的LEVEL 0备份作为起点；若找不到，则报错或退化为差异式（取决于CONFIGURE BACKUP OPTIMIZATION设置） - 真正“自上次任意增量以来”的行为需显式指定：
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE（累积式）或BACKUP INCREMENTAL LEVEL 1 DIFFERENTIAL DATABASE（差异式，默认）
实际执行时最常踩的坑
命令看似简单，但环境细节决定成败：
- 路径权限问题：RMAN 进程以 Oracle 用户身份运行，
FORMAT路径必须对该用户可写，且空间充足。常见错误：ORA-19504: failed to create file "/backup/rman/xxx" - 未
CATALOG就恢复：如果把备份片手动拷到另一台机器，RMAN 不知道它的存在，RESTORE会提示 “no backup found”。必须先运行：CATALOG START WITH '/path/to/backup/'; - 忽略归档日志：增量备份只含数据块变更，恢复时仍需对应时间段内的归档日志。若只备份了增量、没备份归档，
RECOVER DATABASE会卡在“找不到归档” - SCN 手动指定风险高：用
FROM SCN方式（如BACKUP INCREMENTAL FROM SCN 1234567 DATABASE）绕过自动查找逻辑，但一旦 SCN 不准（比如低于数据文件头的checkpoint_change#），恢复会失败
一个最小可行的增量备份脚本
不追求全自动策略，只保证每次执行都可靠：
run {
allocate channel c1 device type disk format '/backup/rman/inc_%U';
backup incremental level 1 database plus archivelog delete input;
release channel c1;
}
说明：plus archivelog delete input 表示同时备份当前归档并清理已备份的归档（防止磁盘爆满）；delete input 不影响恢复所需日志，因为 RMAN 自动保留恢复窗口内必需的日志。
注意：这个脚本隐含依赖上一次 LEVEL 0 存在。如果不确定，先跑一次 BACKUP INCREMENTAL LEVEL 0 DATABASE; 再执行上述。
