采用Beedup实现数据库实时同步，主库环境Oracle RAC+ASM，内存64G，历史数据19T，日增归档100G，从库单实例环境，内存192G。

以下是项目实施过程遇到的主要问题：

1 历史数据同步

启用Beedup批量复制功能（通过数据库链接主从库直接复制表数据），但在复制BLOB表时由于表记录数太多(6000万)导致执行周期太长而失败。尝试Oracle导入导出方式（IMP/EXP），同样由于记录数太多而失败。

扩展Beedup程序，增加全量数据断点续传功能，在复制BLOB表失败后通过断点分批同步数据最终完成所有表历史数据同步。

2 实时增量同步

在Beedup中指定日志捕获起点后开始从日志文件中解析同步增量数据，但是同步延迟很大，难以满足实时同步要求。

依次对主从服务器内存、网络、IO进行分析，最终确定性能瓶颈在于主库的归档读取性能，Oracle RAC的2个实例归档位置指向不同的ASM磁盘组（+FRADG和+DATADG），而其中一个实例的归档与数据文件共用同一磁盘组（+DATADG），由于业务数据频繁写入，导致该磁盘组的归档读取性能很低。

将2个实例的归档位置合并到同一磁盘组（+FRADG），实现业务数据IO独立于归档IO。

归档位置合并后的日志读取性能大幅提升，原来导入1G数据需要7秒，而调整后不到3秒，虽然该值与测试环境性能（单实例操作系统存储，导入1G日志不到300ms）差距较大，但可以满足每日100G新增日志的同步。