RMAN增量备份未提速的根本原因是BCT未启用或未被实际调用、并行通道未显式分配、归档日志未按策略清理；三者缺一即导致LEVEL 1仍全扫描文件，I/O压力反超全备。
增量备份本身不能自动缩短窗口，必须配合通道并发、块变更跟踪（bct）和归档策略三者协同，否则 level 1 备份可能比全备还慢。
为什么 backup incremental level 1 没变快？
常见错误是只改了命令，没验证底层是否真跳过未改块。RMAN 增量 level 1 默认仍会扫描所有数据文件——除非启用了块变更跟踪（BCT）且实际被调用。不启用 BCT 时，RMAN 必须逐块读取并比对 SCN，I/O 压力反而比全备高。
- 查 BCT 是否真启用：
SELECT status, filename FROM v$block_change_tracking;返回ENABLED且路径可访问才算生效 - 查某次增量是否用了 BCT：
SELECT used_change_tracking FROM v$backup_datafile WHERE incremental_level = 1 AND rownum = 1;必须为YES - BCT 文件损坏或权限不对时，RMAN 静默降级为全扫描，
BACKUP命令不报错，但日志里搜不到using change tracking file
ALLOCATE CHANNEL 并发必须写在 RUN 块里
只配 CONFIGURE DEVICE TYPE DISK PARALLELISM 4 不起作用。RMAN 19c 不会自动分配通道，漏写 ALLOCATE CHANNEL 就退单通道，报 RMAN-01009 或 silently 慢跑。
- 正确写法：
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/bak/ch1/%U'; ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/bak/ch2/%U'; BACKUP INCREMENTAL LEVEL 1 DATABASE; } - 每个通道必须指定独立子目录（如
/bak/ch1/、/bak/ch2/），避免多个进程写同一 NFS 路径触发 lease timeout - 并发数不是越多越好：SSD 环境建议从 4 起步，8 是上限；HDD 环境超过 2 就容易引发
enq: cf - contention
归档日志清理策略影响增量备份速度
如果归档日志堆积过多，BACKUP DATABASE PLUS ARCHIVELOG 会花大量时间扫描和读取归档，拖慢整个增量流程。尤其升级到 19c 后，旧库的 ARCHIVELOG DELETION POLICY 不继承，必须重配。
- 确认当前策略：
SELECT dest_name, deletion_policy FROM v$archive_dest; - 安全配置示例：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY BACKED UP 1 TIMES TO DISK;（若无备库，则用BACKED UP 1 TIMES TO DISK） - 执行前先清理过期归档：
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-2';，避免增量备份过程中反复读取大量旧归档
真正卡住备份窗口的，往往不是命令写错，而是 BCT 文件不可用、通道没显式分配、或归档日志没按策略清理——这三处不检查，调再多参数也白搭。
