块跟踪（BCT）未启用时，RMAN增量备份实际全扫描数据文件，失去增量优势；启用需指定独立路径、使用REUSE选项，且仅对后续LEVEL 1备份生效，验证须查日志或V$BACKUP_DATAFILE视图。
块跟踪（BCT）没启用，RMAN增量备份就不是真增量
oracle 12c 的 backup incremental level 1 如果没开块更改跟踪（block change tracking, bct），rman 实际会逐块读取所有数据文件头 + 每个块的 scn 做比对，等效于全扫描——备份耗时接近全量，根本谈不上“增量优势”。你看到的慢，大概率就是这个原因。
实操建议：
- 先查状态：
SELECT status, filename FROM V$BLOCK_CHANGE_TRACKING;—— 返回DISABLED或空行，说明 BCT 没开 - BCT 文件不能放在
db_recovery_file_dest（FRA）里，避免和归档日志争空间；也不能放 NFS 或 ASM 非镜像磁盘组 - 启用命令必须带
REUSE：执行ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/oradata/orcl/bct.f' REUSE;，否则文件已存在时会报错 ORA-19755 - 启用后无需重启实例，但正在运行的 RMAN 备份会话不会自动生效，得新开一个备份任务才用上 BCT
RMAN 增量备份是否真的用了 BCT？别信命令，看证据
光执行了启用命令不等于生效。BCT 只在 LEVEL 1 增量中起作用（LEVEL 0 是全量，不依赖它），且只对后续的增量有效。
验证方法：
- 在 RMAN 中加
SET DEBUG ON，再跑一次BACKUP INCREMENTAL LEVEL 1 DATABASE;，日志里搜using change tracking file—— 出现才算真命中 - 查视图：
SELECT USED_CHANGE_TRACKING FROM V$BACKUP_DATAFILE WHERE BACKUP_SET_STAMP = (SELECT MAX(BACKUP_SET_STAMP) FROM V$BACKUP_SET WHERE BACKUP_TYPE = 'I');，返回YES才确认本次用了 BCT - 对比
V$RMAN_BACKUP_JOB_DETAILS中的INPUT_BYTES_DISPLAY和OUTPUT_BYTES_DISPLAY：如果前者远大于后者（比如 10TB 输入、200GB 输出），说明跳过了大量未改块；如果两者接近，BCT 很可能没生效，或业务写入太密集导致变更块比例极高
并行通道配多了反而拖慢，关键在物理路径隔离
启用 BCT 后，I/O 成为新瓶颈。盲目增加 CONFIGURE DEVICE TYPE DISK PARALLELISM 数值，常引发锁竞争或 CPU 过载，反而更慢。
实操建议：
- 查当前并行度：
SHOW DEVICE TYPE DISK PARALLELISM;，默认是 1，必须手动调高 - 机械盘阵列（如双控制器 RAID6）建议设为 4；单块 NVMe SSD 可试 8–12，但要同步用
top -H看rman进程线程 CPU 是否持续 >80% - 每个通道必须绑定独立挂载点：比如
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup1/%U';和ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup2/%U';，严禁多个通道写同一目录 - 禁用自动通道：
CONFIGURE DEFAULT DEVICE TYPE TO DISK;后手动ALLOCATE CHANNEL，否则 RMAN 容易把通道分配到低速路径，且无法控制压缩级别
BCT 文件损坏或丢失，RMAN 不报错，只悄悄退化
BCT 文件本身很小（几 MB），但一旦损坏或被误删，RMAN 不会中断备份，也不会报错，而是静默降级回全扫描模式——你只会发现“怎么最近备份突然变慢了”，却找不到明显异常。
这正是最危险的情况：问题存在，但无告警。日常运维中容易忽略检查 BCT 文件权限（Oracle 用户需有写权限）、所在文件系统剩余空间（满则写失败）、以及是否被备份脚本误清理。
