Oracle 19c中，backup incremental level 0与backup database物理内容相似但语义不同：level 0是RMAN增量备份链中唯一有效的父备份，INC_LEVEL=0，支持跳过从未使用块，并被differential增量依赖为最近时间戳父节点；而backup database的INC_LEVEL为NULL/255，不能作为增量父备份，且不利用block change tracking。
oracle 19c 的 backup incremental level 0 和 backup database 在物理内容上几乎一致，但语义和用途完全不同——关键不在“备份了什么”，而在“rman 怎么记、后续怎么用”。
level 0 备份能当增量父备份，全备不能
RMAN 的增量策略依赖元数据链：level 1 备份必须指定一个“父备份”（parent），而这个父备份只能是 level 0 类型的备份记录。即使你手动执行了 backup database，它在 RMAN repository 中的 INC_LEVEL 字段是 NULL 或 255，不会被识别为有效父备份。
实操验证：
SELECT BS_KEY, INC_LEVEL, STATUS, COMPLETION_TIME FROM V$BACKUP_SET WHERE INC_LEVEL IN (0, NULL, 255) ORDER BY COMPLETION_TIME DESC;
你会发现 INC_LEVEL = 0 的记录才能出现在 LIST BACKUP OF DATABASE SUMMARY 中的 “Incremental Level” 列里；而 backup database 生成的备份，该列为空或标为 “Full”。
- 执行
backup incremental level 1 database前，若没有INC_LEVEL = 0的备份，RMAN 会自动触发一次level 0（不是全备）作为垫底 - 手动用
backup database替代level 0，再跑level 1，会报错RMAN-06059: expected archived log not found或直接跳过增量逻辑，退化为全备
全备默认含未使用块，level 0 默认跳过
这是 RMAN 在 backup set 模式下的行为差异，只影响空间和速度，不影响一致性。
-
backup database：默认启用skip unused blocks，但实际是否跳过，取决于底层存储类型和 COMPATIBLE 设置；在 19c 中，若数据库启用了 ASSM + 自动段空间管理，且未显式关闭压缩，它仍可能读取并备份空闲块（尤其在 backupset 中未设as compressed backupset） -
backup incremental level 0 database：强制跳过从未写入过的块（never-used blocks），即只备份used块 —— 这是 Oracle 官方文档明确定义的：“includes every block in the file except blocks compressed out because they have never been used” - 二者都支持
as compressed backupset，但压缩不改变“是否读 unused 块”的逻辑，只影响传输后压缩率
验证方式：对比相同表空间下两个备份的 V$BACKUP_DATAFILE.BLOCKS 与数据文件总块数（DBA_DATA_FILES.BLOCKS），level 0 的 BLOCKS 值通常更小。
差异增量（differential）依赖 level 0 的“最近性”，不是“唯一性”
Oracle 19c 默认使用差异增量（differential），它的查找父备份逻辑是：找最近一次 level 0 或同级 level 1 备份，不是固定锚定某个特定 level 0。
- 如果你周一做了
level 0，周二、三各做了一次level 1 differential，那么周三的level 1只包含周二到周三之间的变化，不是从周一算起 - 但如果你周二做了
level 0，周三再做level 1，那它就以周二的level 0为父 —— RMAN 不关心“哪个 level 0 更早”，只看时间戳最近的那个 - 所以
level 0不是“基线锚点”，而是“可用父节点候选”；真正决定恢复链长度的，是你的level 0执行频率
这点容易被误解：很多人以为 level 0 是不可替代的“根”，其实它只是滚动窗口里的一个可替换节点。
block change tracking 文件对 level 0 无效，但加速 level 1
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 只在 level 1（及更高）备份中生效。RMAN 对 level 0 总是扫描整个数据文件，不管是否开启 BCT。
- 开启 BCT 后，
backup incremental level 1会直接读取CHANGE_TRACKING_FILE，跳过大量未修改块，速度提升显著（尤其大库） - 但
backup incremental level 0完全无视该文件，仍走 full scan 路径 —— 因为它本就是全量逻辑 - 这意味着：如果误把
level 0当作日常备份主力（比如每天跑一次），BCT 带来的性能收益就浪费了；应让level 0少而稳（如每周一次），level 1多而快
最常被忽略的一点：即便你开了 BCT，level 0 依然慢，而且日志里不会报错或警告 —— 它就安静地全扫，没人提醒你“这个配置对你当前命令没用”。
