觸發器遷移數據和Oracle 物化視圖(MV)的原理相同，通過在源表創建Trigger，記錄源表的DML操作日誌，然後通過存儲過程同步DML受影響的記錄，達到目標表和源表數據一致的效果。此方法只是對Prebuilt MV操作的一個補充。物化視圖/在線重定義對DML頻繁的大表進行處理時，存在一個弊端，主要是在全量初始化這個步驟上，比如: 本應該多塊掃描，直接路徑讀效率很高的，但由於個別數據塊在內存造成單塊讀; 或由於DML操作相對頻繁，可能讀到的數據需要與undo構造一致性讀數據塊的機率也較高，此時查看等待事件都是採用單塊讀方式，從表面現象來看剛開始同步時同步速度很快，越到後面越慢，最終無法快速完成或出現快照過舊問題。當然，在DML頻繁的表上創建Trigger，會源表的DML性能造成影響，需要提前評估。對於一些小表的同步，仍然建議使用Prebuilt MV，原因簡單方便，此思想也適合於其他數據庫。
本示例實現目標：
將源端
user01.user_table 表數據遷移至目標端 user02.user_table，並實現目標端數據與源端數據定期實時的數據一致性同步。若進行業務遷移，對業務影響控制在1分鐘時間內並，選擇合適的時間點切換，基本可以做到重啓應用程序所需時間，換句話說就是對業務的影響取決於應用程序的重啓時間。
數據庫源 端：業務數據庫1
數據庫目標端：業務數據庫2
源 端 user01.user_table表：
表大小：60GB+，記錄數：4.8億+，每天DML量：200W左右，晚上22點後至第二天早上8點DML量較少，此時間段爲空閒時間段，可在此時間段做初始化操作；
採用user_id做hash分區，分區數：16，主鍵字段：user_id+serviceid，唯一索引字段：uin+serviceid；
目標端 user02.user_table表：
採用uin做hash分區，分區數：64，主鍵字段：uin+serviceid，唯一索引字段：user_id+serviceid（目前生產庫上依據業務情況，已不用該索引查詢）。
限制：
1、源表需要有主鍵或者非空的唯一約束；
2、在同步期間，不支持對源表做DDL操作（注: 可以改進代碼達成支持DDL的效果）;
3、DML頻繁的表不適合，可能會導致增量跟不上（注：沒標準，取決於數據庫性能）。
實施步驟簡要說明：
注：紅色字體爲目標端操作，綠色字體爲源端操作。
1、創建目標表：user02.user_table，並打開行移動（alter table
user02.user_table enable row
movement;），源端會對uin進行update，暫且不創建索引，待全量同步完成後創建索引，以免影響全量同步速度；
2、創建同步狀態表（user02.rep_table_flag），用於記錄同步存儲過程運行狀態；
3、創建錯誤日誌表（user02.os_err_info）及序列（user02.seq_os_err_info
注：如果計劃該表是和業務系統共用，請建成範圍分區表）；
4、創建同步日誌表（user01.user_table_rep_sync_log）及序列（user01.seq_user_table_rep_sync_log），用於記錄源表的DML操作信息；
5、創建觸發器（user01.trigger_user_table_rep），將捕獲的到信息插入日誌同步表（注：創建觸發器在改業務表空閒時間段進行，減少DML日誌量生產，並對業務影響較小，並且一定要在全量同步前創建）；
6、創建目標庫連接源數據庫的dblink（TO_XXXXX.LOCALDOMAIN），並且對同步同步表user01.user_table_rep_sync_log有DML權限；
7、創建增量數據同步存儲過程（user02.proc_user_table_repl）；
8、全量同步源表數據至目標表，如：exp/imp、impdp無落地遷移、存儲過程拉數據等均可，本示例採用存儲過程拉數據；
9、爲目標表創建主鍵及相關索引；
10、以上完成後在目標庫執行數據同步存儲過程（user02.proc_user_table_repl），可建job定時刷新；
11、監控同步日誌表（user01.user_table_rep_sync_log），觀察需要同步的數據量。
如果做業務系統割接則需要業務程序配合，監控需要同步的數據量在刷新間隔時間期間最少時，停止定時刷新job，關閉舊業務程序，在目標庫手動執行同步刷新直至同步日誌表無新記錄生成，啓動新業務程序，以達到對業務系統影響最小的效果。