在實施goldengate過程中，初始化的方案選擇是一個重要的環節，尤其對一個7*24小時的系統環境來講。一個出色的 goldengate的實施不應該以停機時間作爲代價，合適的初始化方法完全可以做到零停機。
如果事務不間斷進行，如何保證初始化過程中事務的完整性和數據的準確性呢(靜態的初始化環境無需多講)？實現方法還是多樣的，從工作機制上來講，歸納起來主要有2種。
1. 利用 Keys + Handlecollisions
2.利用 commit SCN/CSN
Handlecollisions參數依賴於表上的Key(Primary key/Unique key)來對數據進行重複行和缺失行的處理，常在數據初始化過程中保證數據的一致性，gg文檔上的初始化辦法，比如initial load，都是用的這種辦法。但是這種辦法在實際的工程實施中是有相當大的限制。
首先，該初始化辦法性能比較糟糕，對於大型數據庫來講，並不合適。更嚴重的是，它有很大的缺陷性。(引自metalink doc)：
1. When there is primary key update (PKUpdate), the HANDLECOLLISIONS method may lose data. The solution in the case of a primary key update is for Extract to fetch whole row by making a flashback query. However, this is not efficient and may not be possible in certain environments.
2. When a table does not have any type of key, HANDLECOLLISIONS may introduce duplicate rows in the table. One workaround is to add a primary or unique key to the target table.
3. The exact timestamp when the initial load was started may not be known (and different tables may have different start times), so it is almost inevitable that HANDLECOLLISIONS will be used for certain records un-necessarily. This could mask a real data integrity problem.
在實際的工程實施中，個人不推薦使用基於Keys + Handlecollisions模式的初始化辦法。
那麼基於commit SCN的初始化辦法是否可靠呢？如果你用過邏輯備庫，Stream等東西，退一步講，抑或是做過一致性的導入導出，應該很清楚SCN在版本一致性方面的重要作用。
問題簡單化，goldengate初始化的的核心問題就變成了如何聯機進行基於SCN一致性的同步。實現的工具和方法還是不少的。
1. 一致性的exp和imp
2. 一致性的expdp和impdp
通過exp和expdp的一致性參數(例如flashback_scn)，導出特定SCN點上的一致性版本，使用這種方法初始化存在一個問題，就是構造一致性數據過程中會對undo造成比較大的壓力，尤其對大型數據庫來講，可以通過分割的datapump來實現數據的分組同步，分散undo的壓力，然後合適時間將分組的datapump合併即可。
該方法的優點就是可以跨平臺和跨版本初始化。
3. 基於備份的表空間搬移（Transportable Tablespace from Backup with RMAN）
爲何是基於備份的表空間搬移呢? 單純的表空間搬移需要數據庫或者表空間read only，copy數據文件的這段時間應用是需要停止的，因此表空間搬移並不適合7*24小時的初始化環境。
基於備份的表空間搬移的一個最大的優勢就是零停機，而且支持異構平臺和跨版本（對於不同字節順序的source-target平臺初始化，需要進行convert），但是需要10g以上版本才支持，同樣受到表空間搬移的那些限制條件。
4. Dataguard
Dataguard適合同平臺同版本的系統環境初始化。
當然，在實際工程中，還會有別的一些處理辦法，或者各種辦法之間有交融，作爲方案制定者和實施者，你所能駕馭的，就是對你來說合適的。
原文鏈接：http://www.easyora.net/blog/goldengate_initialization.html