必须手动启用块更改跟踪（BCT），否则RMAN LEVEL 1增量备份退化为全文件扫描；确认方法是查v$block_change_tracking视图，status为DISABLED即未启用，ENABLED且bytes>0才生效，启用后需验证used_change_tracking为YES方可确认真正使用。
块更改跟踪（bct）必须手动启用，否则 rman 的 level 1 增量备份永远在全扫描数据文件——这不是性能瓶颈，是功能缺失。
怎么确认 BCT 没开？看 v$block_change_tracking
直接查视图比翻文档快：
SELECT status, filename, bytes FROM v$block_change_tracking;
返回结果只有三种可能：
-
DISABLED：明确没开，路径和大小字段为空或 NULL - 空结果集：实例没权限查该视图（用
sys或sysdba登录重试） -
ENABLED+ 有filename+bytes> 0：已生效
别信“我上周配过”，很多环境 DBA 执行了 ALTER DATABASE ENABLE... 但没检查返回值，或路径写错导致静默失败。
启用 BCT 的关键实操细节
命令本身简单，但路径、权限、存储位置三处最容易出错：
- 路径必须显式指定，不能依赖
DB_CREATE_FILE_DEST—— 否则可能落到 FRA（db_recovery_file_dest）里，和归档日志抢空间 - Oracle 用户对目标目录要有读写权限：
chown oracle:oinstall /u01/oradata/ORCL/，再chmod 755 - 禁止放在 NFS、ASM 非镜像磁盘组、裸设备上；推荐放本地高性能 SSD 或高可用 SAN 卷
- 执行命令：
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/oradata/ORCL/bct.dbf';
成功后立即生效，无需重启；但正在运行的 RMAN 备份会话不会自动切换，下一次 BACKUP INCREMENTAL LEVEL 1 才开始用 BCT。
RMAN 真的用了 BCT 吗？别只看命令，要验证
启用 ≠ 生效。验证方式有两种：
- 加调试日志：
SET DEBUG ON后跑一次BACKUP INCREMENTAL LEVEL 1 DATABASE;，在日志里搜using change tracking file—— 出现才算真用上了 - 查视图：
SELECT used_change_tracking FROM v$backup_datafile WHERE incremental_level = 1 AND rownum = 1;返回YES表示本次备份启用了 BCT - 对比字节数：
v$rman_backup_job_details中INPUT_BYTES_DISPLAY（扫描量）远小于OUTPUT_BYTES_DISPLAY（实际备份量），说明跳过了大量未改块
BCT 文件损坏时 RMAN 不报错，而是静默降级回全扫描——所以备份变慢却查不到报错，第一反应就该查 v$block_change_tracking 和 used_change_tracking。
BCT 文件不是“设了就完事”，得盯住它的生命周期
它很小（几 MB），但有隐性约束：
- 自动管理位图，最多保留最近 8 个备份周期的变更记录；超过后最旧位图被覆盖
- 如果做了一次 LEVEL 0，接着做了 7 次 DIFFERENTIAL LEVEL 1，再做 CUMULATIVE LEVEL 1，RMAN 可能无法优化——因为对应 LEVEL 0 的位图已被覆盖
- 文件不参与 RMAN 备份，也不能用 RMAN 恢复；丢了就重建：
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;再ENABLE - 不要用
rm -f直接删文件，先DISABLE，否则下次启动可能报ORA-19755
BCT 是 Oracle 10g 就有的老功能，但直到 19c 仍默认关闭；很多 DBA 把它当成“高级选项”忽略，其实它是增量备份的基础设施——就像没开索引的查询，再怎么调优 SQL 也快不起来。
