採用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新增日誌的同步。
