RMAN增量备份适合DG备库同步，因它不依赖主库实时IO，仅用归档日志和增量备份集即可将备库拉至接近实时状态，减轻高负载时业务压力，并适配带宽受限或主库不可停顿场景。
为什么RMAN增量备份适合DG备库同步
直接用DUPLICATE FROM ACTIVE DATABASE在主库高负载时容易拖慢业务，而RMAN增量备份把压力拆到非高峰时段，还能复用已有的备份策略。关键在于：它不依赖主库实时IO，只靠归档日志+增量备份集就能把备库拉到接近实时状态，特别适合带宽受限或主库不能停顿的场景。
备库必须先有基础物理结构才能增量同步
增量备份不是从零开始——备库得先通过一次全量RMAN恢复（比如DUPLICATE TARGET DATABASE FOR STANDBY或RESTORE DATABASE + RECOVER DATABASE）建立和主库一致的文件布局、SCN起点和控制文件。否则RECOVER DATABASE会报ORA-01152: file 1 was not restored from a sufficiently old backup。
- 主库打0级备份后，传到备库并
RESTORE DATABASE - 再用
RESTORE STANDBY CONTROLFILE覆盖控制文件（别用CREATE STANDBY CONTROLFILE，它不带standby redo信息） - 启动到
MOUNT状态，确认V$DATABASE.DATABASE_ROLE = 'PHYSICAL STANDBY'
RMAN增量备份同步的关键命令与参数
主库执行增量备份后，需把备份集、归档日志、控制文件备份一并传到备库。核心恢复命令是RECOVER DATABASE，但它默认只应用归档，不自动识别增量备份集——必须显式指定。
- 先注册所有新文件：
CATALOG START WITH '/backup/incremental/'; - 再强制应用所有可用备份：
RECOVER DATABASE NOREDO;（NOREDO表示跳过在线日志，只用归档+备份集） - 如果报
ORA-19573: cannot obtain exclusive enqueue for datafile，说明数据库没在MOUNT状态，或者有数据文件被open - 增量备份级别要连贯：比如主库做了
LEVEL 0→LEVEL 1 CUMULATIVE→LEVEL 1，备库恢复时NOREDO能自动按依赖顺序应用；但混用DIFFERENTIAL和CUMULATIVE可能漏块
最容易被忽略的三个坑
增量同步失败往往卡在细节：不是命令写错，而是环境没对齐。
-
DB_UNIQUE_NAME主备必须不同，但DB_NAME必须完全一致，否则RECOVER会拒绝应用备份集 - 备库的
LOG_ARCHIVE_DEST_2必须指向主库，且VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)——否则MRP进程起不来，增量日志进不来 - 主库开启
BLOCK CHANGE TRACKING能加速增量备份生成，但备库不需要开；开了反而可能因路径不存在导致ALTER DATABASE RECOVER MANAGED STANDBY DATABASE报错
真正难的不是跑通一次，而是让增量同步变成可重复、可验证的运维动作——每次传完备份集，务必在备库执行LIST BACKUP OF DATABASE确认文件可见，再RECOVER DATABASE TEST预演一遍，别等切换时才发现控制文件版本不匹配。
