從根本上講，OGG復制性能和要復制的表是否存在主鍵和唯一索引有很大關系，所以從應用系統開發商對表結構的規范更為有效。OGG調優通常采用拆分進行的方式，拆分方法如下所述。
Extract拆分方法
1) 停止extract進程
2) 停止datapump、進程
GGSCI> INFO datapump_name
EXTRACT DPEF Last Started 2011-01-28 12:34 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:05 ago)
Log Read Checkpoint File ./dirdat/ef000010
2011-01-28 12:47:45.000000 RBA 148645
直至RBA號不變化，才能停止
3) 停止replicat進程
GGSCI> INFO replicat_name
REPLICAT RPEF Last Started 2011-01-28 12:30 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:05 ago)
Log Read Checkpoint File ./dirdat/ef000006
2011-01-28 12:47:45.000000 RBA 149258
直至RBA號不變化，才能停止
4) 記錄extract檢查點
Extract檢查點包括：Recovery Checkpoint和Current Checkpoint
GGSCI> INFO extract_name, SHOWCH
EXTRACT EXEE Last Started 2011-01-28 09:58 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:01:02 ago)
Log Read Checkpoint Oracle Redo Logs
2011-01-28 10:02:16 Seqno 26, RBA 7090688
Current Checkpoint Detail:
Read Checkpoint #1
Oracle Redo Log
Startup Checkpoint (starting position in the data source):
Sequence #: 26
RBA: 289296
Timestamp: 2011-01-28 09:27:31.000000
Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Sequence #: 26
RBA: 7088144
Timestamp: 2011-01-28 10:02:16.000000
Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
Current Checkpoint (position of last record read in the data source):
Sequence #: 26
RBA: 7090688
Timestamp: 2011-01-28 10:02:16.000000
Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 11
RBA: 31609
Timestamp: 2011-01-28 10:02:19.072000
Extract Trail: ./dirdat/ee
Header:
Version = 2
Record Source = A
Type = 4
# Input Checkpoints = 1
# Output Checkpoints = 1
File Information:
Block Size = 2048
Max Blocks = 100
Record Length = 2048
Current Offset = 0
Configuration:
Data Source = 3
Transaction Integrity = 1
Task Type = 0
Status:
Start Time = 2011-01-28 09:58:34
Last Update Time = 2011-01-28 10:02:19
Stop Status = G
Last Result = 400
5) 修改原有相應的參數文件，將拆分出的表從參數文件中刪除
6) 增加新的extract，datapump和replicat
--source--------------------------------------------------
GGSCI (win2k364) 15> add ext exef, tranlog, begin now
EXTRACT added.
GGSCI (win2k364) 16> add exttrail ./dirdat/ef, ext exef, megabytes 50
EXTTRAIL added.
GGSCI (win2k364) 17> add ext dpef, exttrailsource ./dirdat/ef
EXTRACT added.
GGSCI (win2k364) 18> add rmttrail ./dirdat/ef, ext dpef, megabytes 50
RMTTRAIL added.
--target--------------------------------------------------
GGSCI (win2k364) 21> add rep rpef, exttrail ./dirdat/ef
REPLICAT added.
7) 修改新增extract進程的檢查點
檢查點為上面記錄的兩個檢查點：
current read checkpoint and recovery checkpoint
--修改current read checkpoint
GGSCI (win2k364) 30> alter exef extseqno 26, extrba 7090688 [, thread n]
EXTRACT altered.
--修改recovery checkpoint
GGSCI (win2k364) 4> alter exef ioextseqno 26, ioextrba 7088144 [, thread n]
2011-01-28 10:46:18 INFO OGG-00989 WARNING: Unsupported operation. This might cause transactional inconsistency. Modifying iocheckpoint: ioseq = 26 iorba = 7088144.
Are you sure you want to continue? y
EXTRACT altered.
8) 確認所有參數文件正確，啟動進程即可
Datapump和replicat拆分方法
下面以拆分replicat為例，datapump拆分方法相同。
1) 停止replicat進程
2) 查看檢查點
GGSCI> INFO replicat_name, SHOWCH
REPLICAT RPEF Last Started 2011-01-28 12:30 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:03 ago)
Log Read Checkpoint File ./dirdat/ef000006
2011-01-28 12:47:45.000000 RBA 149258
Current Checkpoint Detail:
Read Checkpoint #1
GGS Log Trail
Startup Checkpoint (starting position in the data source):
Sequence #: 4
RBA: 1845
Timestamp: 2011-01-28 11:32:10.556000
Extract Trail: ./dirdat/ef
Current Checkpoint (position of last record read in the data source):
Sequence #: 6
RBA: 149258
Timestamp: 2011-01-28 12:47:45.000000
Extract Trail: ./dirdat/ef
Header:
Version = 2
Record Source = A
Type = 1
# Input Checkpoints = 1
# Output Checkpoints = 0
File Information:
Block Size = 2048
Max Blocks = 100
Record Length = 2048
Current Offset = 0
Configuration:
Data Source = 0
Transaction Integrity = -1
Task Type = 0
Database Checkpoint:
Checkpoint table = GGS.GGSCHKPT
Key = 746337239 (0x2c7c33d7)
Create Time = 2011-01-28 10:20:18
Status:
Start Time = 2011-01-28 12:30:23
Last Update Time = 2011-01-28 13:25:34
Stop Status = A
Last Result = 400
3) 修改原有參數文件，將拆分出的表刪除
4) 新增replicat，和拆分前的進程讀取相同的隊列文件
5) 修改檢查點
6) GGSCI>alter replicat_new extseqno 6, extrba 149258
7) 確認所有參數文件無誤，啟動進程即可
OGG的Replicat進程性能調優
OGG的Replicat負責將隊列文件中的數據讀取出來然后按照原來的順序一條條投遞到目標數據庫，當數據變化量較大時可能無法跟上隊列的產生速度，此時需要進行調優。
OGG提供幾個參數用於調節Replicat的性能，如batchsql/ MAXTRANSOPS /GROUPTRANSOPS等。
Replicat的性能問題除去數據變化量的大小，還跟數據庫本身執行SQL的速度有關。例如，表是否有主鍵或者唯一索引，是否有普通索引等，也可以通過這些方面進行調優。
確認Replicat進程運行正常
可以使用stats myrep來查看進程的統計信息，或者使用send myrep,report強制執行一個報告，然后使用view report查看報告里面的各表的統計信息，觀察數據變化量是否比較大。
如果replicat長時間不動，可以嘗試重啟該進程，觀察是否正常響應，有可能該進程正在處理一個長事務，會報告正在處理長交易和已經處理了多少條。
Replicat進程的拆分
拆分原則
Replicat如需拆分，按照schema、業務所涉及表范圍、表名稱前綴、表名等方法進行依次拆分。
拆分進程的評估
可以在extract運行幾天后，查看源端extract的報告或者使用stats命令找出變化最為頻繁的表，為一個或幾個這些大數量級表單獨配置投遞進程；也可根據數據庫定期收集的統計信息將變化較多的表拆分出來；無主鍵表往往性能較差，對於單個或多個頻繁變化的無主鍵表一般也需要拆分為獨立的進程；同時也可以根據Trail產生的速度和實際Replicat的速度來估算需要多少個進程。Repliat的拆分一般很難一次到位，經常需要多次拆分方能達到最佳效果。
進程拆分的目標
進程拆分一般以表為單位，當對某一個進程進行拆分后，其所負責的全部表應當被分布到各個拆分后的進程去，既要保證全部被包含到這些進程，又要確保不會有表被重復包含在多個進程中。例如，對原來一個Schema進行拆分，將其中一個大表拆分為一個單獨進程：
拆分之前的Replicat中的map：
map UCR_UIF1.*, target UCR_UIF1.*;
拆分后的兩個Replicat中的map：
第一個replicat，只包含拆分出來的大表(需要新加一個replicat，可以copy原有replicat創建的命令和參數，注意替換掉所有與進程名有關的參數)：
Map UCR_UEC.TF_O_SELFSERVICE_STATE, target UCR_UEC.TF_O_SELFSERVICE_STATE;
第二個replicat，將該大表排除出去后的所有該schema下的表(可以直接用舊的replicat，只需添加mapexclude參數即可)：
MAPEXCLUDE UCR_UEC.TF_O_SELFSERVICE_STAT
map UCR_UEC.*, target UCR_UEC.*;
拆分的步驟
以下為一個replicat進行拆的步驟：
1) 停止所要拆分的replicat；
2) 使用info myrep查看該replicat的檢查點，將該檢查點所有內容記錄下來。如下示例，記住當前的隊列號seqno和RBA：
Last Started 2006-01-21 11:40 Status RUNNING
00:00:00 (updated 232:39:41 ago)
C:\GGS\DIRDAT\RT000123
2006-01-11 18:54:33.000000 RBA 4735245
3) 根據評估決定要拆分為幾個進程，為每個進程准備創建命令和參數文件，務必要仔細檢查，確保其正確性；
4) 執行ggsci命令創建replicat進程，通過edit param myrep編輯參數文件或直接將參數文件放到dirprm目錄下；
5) 針對新增的replicat（原有的replicat就不用動了），逐個修改其檢查點到原replicat指定的extseqno和extrba。例如，針對上面的示例：
ALTER REPLICAT mynewrep, EXTSEQNO 123, EXTRBA 4735245
6) 檢查各replicat的參數和進程信息，確保表已經被散步到各個進程，確保各進程檢查點已經與原有replicat保持一致；
7) 啟動replicat，觀察是否正常。
說明：進程的拆分需要對replicat的檢查點進行操作，一定要特別注意，如有可能需求技術支持。
針對單個表的拆分
如果某些表特別大，拆分到一個單獨進程依然無法滿足要求，可以根據主鍵將該表拆分為多個進程。
注意：單個表的拆分是依據某個字段的值做hash進行拆分的（默認為主鍵，但也可以自定義為其它列，前提是該列必須被記錄在附加日志里面），所以必須要保證該字段日常是固定不變的。否則，作為拆分依據的這些字段的變化將會引起記錄在不同的replicat中處理，有可能各進程之間的不同不會引起數據修改順序的紊亂，導致replicat出錯。
下面是一個拆分后的replicat參數示例，原有進程被拆分為2個進程：
原來的replicat：
MAP sales.acct, TARGET sales.acct;
拆分后的Replicat1（可使用原有的replicat）：
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (1, 2));
拆分后的replcat2（新增）：
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (2, 2));
具體拆分步驟與依據表的拆分相同，不再詳述。
單個Replicat進程的調優
OGG提供了幾個參數可以對單個的replicat進行調優，如下所示：
1) 使用操作合並 - BATCHSQL
BATCHSQL
該參數可以將類似的SQL放在一起進行批量提交。該參數適用的條件：
ü Replicat進程里面只有一張或者幾張表；
ü 這些表沒有BLOB/CLOB/LONG等大對象；
ü 這些表的列定義長度在1K以下，例如如果有幾個varchar(4000)則不合適；
更多信息請參考OGG的參考手冊，如需使用請聯系技術支持。
2) 對大交易使用交易分拆 - MAXTRANSOPS
MAXTRANSOPS 1200
將超過指定的記錄變化數的交易拆分為多個小一些的交易進行提交，可以不必等待OGG讀完全部的交易記錄，能夠看到檢查點的持續前進。
如果有時候Replicat很長時間不往前移動，可以考慮調整該參數。
3) 對於密集小交易使用交易合並 - GROUPTRANSOPS
GROUPTRANSOPS 1200
該參數的作用是將小交易合並為一個大一些的交易，示例是將若干小交易拼在一起直到所有的記錄超過500個則將這些交易一起提交。可以有效降低密集小交易帶來的密集IO，提升投遞性能。對於大交易不起作用，一般性能調優在IO有瓶頸時使用。
數據庫及SQL的調優
OGG的復制機制是將源端發生的變化拼裝為SQL在目標端重現，其執行的速度與本身sql的速度有關。尤其是對於update和delete，對於執行計划的優化可以極大的提高sql執行的速度。
一個典型的問題是無主鍵表，當執行一個update或這delete時，無主鍵表會執行全表掃描去定位一條記錄，速度非常慢。因此，當無主鍵表拆分為一個進程依然無法滿足其性能要求時，其最佳方法就是給該表加入主鍵或唯一索引。
其它對於目標庫的sql執行效率優化也同樣能提高OGG replicat的性能。
申請技術支持
如經過以上排查仍然無法解決性能問題，可以聯系Oracle予以協助。
OGG進程拆分與交易一致性說明
1) 問題描述
國網部分網省對於OGG進程拆分會不會影響交易一致性比較關心，特在此予以說明。
2) 問題說明
OGG的extract/data pump/replicat進程均可以拆分為多個進程同時並發執行，以提高數據復制的性能和處理能力。在Oracle提供的《國家電網網省數據級災備GoldenGate設計原則》一文中對於進程的拆分原則進行了詳細的規定。下面對於各個進程的拆分及其交易一致性的影響進行分析：
ü 主Extract的拆分
在前期提供的OGG鏈路設計原則中提到，OGG的主Extract進程處理能力較強，一般依據硬件平台不同可以處理約每小時20-40G以上的日志，對於中小型應用無需拆分；而如果數據量較大，確實需要拆分的話，優先選擇的是以業務或schema作為拆分的依據，即按照不同的業務所設計的表范圍拆分extract進程。
按照業務拆分完成后，各extract進程之間沒有交互，相互獨立運行，之間可能會有時間差，但是由於各進程是以業務為依據進行拆分的，只會在不同的業務之間產生時間上的短暫差異，並不影響交易的一致性；
如果拆分時打破了業務界限，同一個業務被拆分到了不同的extract進程里面，則出現災難時可能會出現不同進程之間的數據不平衡。如果確有這種情況，可以通過OGG的logdump工具對最后的幾條數據進行檢驗，人工處理掉這幾條不一致的數據。需要說明的是OGG處理日志速度很快，這種幾率是非常低的。
總而言之，當extract沒有拆分或者按照業務進行拆分，則不會帶來交易的不一致性；如果打破了業務范圍進行拆分，則有可能會帶來交易不一致性，可通過logdump找出不一致的數據進行人工處理，而實際發生的概率是非常低的。
ü Data pump的拆分
Data Pump是跟extract嚴格一對一的，目前不針對data pump進行拆分，對於它們沒有該問題。
ü Replicat的拆分
由於單個replicat相對於extract處理能力較慢，當前大部分網省都對replicat進行了拆分。拆分后的replicat單獨運行，相互不進行交互，彼此之間同樣可能存在不同步現象，依據extract的拆分情況分析如下：
當extract不拆分或者按照業務拆分時，能夠保證交易的一致性，其對應的trail文件所包含數據均是一致的，而被傳輸到目標端后，replicat雖然彼此之間速度稍有差異（一般在幾秒或者零點幾秒之內），但是在接管過程中，由於切換需要至少幾分鍾或者幾十分鍾時間，此過程中由於trail已經停止增長，各replicat已經完全可以處理完隊列中的數據，這樣雖然入庫時間稍有差異，但最終數據是全部隊列中數據均已進入數據庫，而隊列中數據的交易一致性已經由extract進行保證，不會帶來交易不一致；
只有當源端extract沒有按照業務拆分時，目標的多個trail可能會有短暫的數據差異，replicat會把這些交易全部提交到目標端。此時可以通過logdump查看隊列中最后的幾筆交易，確認其scn號是否一致，如確有不一致可以人工進行處理，該情況只在極端情況下出現。
OGG延遲lag較大的說明
1) 問題描述
對於有lag的進程，顯示為running，屬於正常狀態。但是如果lag時間過長，是否還正常，多長時間的范圍屬於正常。這個需要oracle工程師做出解釋。
2) 問題說明
OGG的lag指的是數據復制的延遲，對於不同的進程lag較長時分析如下：
ü 主Extract的lag較大
主Extract負責對於數據庫的日志做解析獲取數據變化，只要正常運行時其延遲一般都在秒一級左右。如果出現了較大的延遲，首先排查是否存在大交易，可能進程正在處理中；如果沒有大交易，但是延遲卻非常大，請聯系技術支持予以調查。
ü Data Pump的lag較大
Data Pump負責數據的傳輸，如果出現較大延遲可能是因為網絡出現問題，首先可以觀察網絡帶寬是否被占滿，也有可能短時間內產生了較多的數據變化。
ü Replicat的lag較大
Replicat負責數據的入庫，一般速度相對於主extract和data pump較慢，容易產生較大延遲。當replicat出現延遲后，需要對進程進行調優或者拆分，具體步驟參照本文檔上一節。
一般調優完成后，在日常業務狀態下應當不存在較大延遲（一般幾秒到一分鍾以內）；當出現批處理時，可以允許一定的延遲，一般以不影響第二天的正常業務為准 – 例如，如果批處理每天早上4點前結束，可以控制延遲在2小時以內。
因此，首先需要確定OGG復制所允許的最大延遲在日常業務和批處理時的目標是什么，然后一旦達不到此目標就要依據上一節的方法進行性能的調優。