GoldenGate 應用系統升級
（僅復制DML時）源端和目標端數據庫增減復制表
增加復制表
在GoldenGate的進程參數中，如果通過*來匹配所有表，因此只要符合*所匹配的條件，那麽只要在源端建立了表之後GoldenGate就能自動復制，無需修改配置文件，但是需要為新增的表添加附加日誌。
步驟如下：
GGSCI 〉dblogin userid goldengate, password XXXXXXX
GGSCI > info trandata <schema>.<table name>
如果不是enable則需要手動加入：
GGSCI > add trandata <schema>.<table name>
註：（僅對Oracle 9i）如果該表有主鍵或者該表不超過32列，則顯示enabled表示添加成功；如果無主鍵並且列超過32列，則可能出現錯誤顯示無法添加則需要手工處理，此時請根據附錄二中方法手工處理。
如果沒有使用統配符，則需要在主Extract、Data Pump裏面最後的table列表裏加入新的復制表；在目標端replicat的map列表同樣也加入該表的映射。
然後，新增表請首先在目標端建立表結構。
如果有外鍵和trigger，需要在目標表臨時禁止該外鍵和trigger，並維護在dirsql下的禁止和啟用這些對象的對應腳本文件。
對於修改了文件的所有源和目標進程，均需重啟進程使新的參數生效。
減少復制表
GoldenGate缺省復制所有符合通配符條件的表，如果有的表不再需要，可以在源端drop掉，然後到目標drop掉，無需對復制做任何修改。
如果其中幾個表依然存在，只是無需GoldenGate復制，則可以通過以下步驟排除：
1) 在源端系統上首先驗證所需歸檔日誌存在後通過stop extXX停止對應的extXX進程；
2) 在目標端系統上ggsci中執行stop repXX停止目標端的復制進程；
3) 在源端修改ext進程的參數文件排除所不復制的表:
Ggsci> edit param extXX
……
tableexclude ctais2.TMP_*;
tableexclude ctais2.BAK_*;
tableexclude ctais2.MLOG$_*;
tableexclude ctais2.RUPD$_*;
tableexclude ctais2.KJ_*;
tableexclude myschema.mytable;
table ctais2.*;
…….
在文件定義table的行前面加入一行“tableexclude <schema>.<tablename>;” 註意寫全schema和表的名稱。
註：如果是沒有使用通配符，則直接註釋掉該表所在的table行即可。
1) 在目標端修改rep進程參數，同樣排除該表:
GGSCI>edit param repXX
在map前面加入一行：
--mapexclude CTAIS2.SHOULIXINXI
mapexclude myschema.mytable
MAP ctais2.* ,TARGET ctais2.*;
註：如果是沒有使用通配符，則直接註釋掉該表所在的map行即可。
2) 在目標端系統上啟動復制進程 repXX
GGSCI > start repXX
3) 在源端系統上啟動源端的抓取進程extXX
GGSCI > start extXX
即可進入正常復制狀態。
（僅復制DML時）修改表結構
當數據庫需要復制的表結構有所改變，如增加列，改變某些列的屬性如長度等表結構改變後，可以按照下列步驟執行：
1) 按照本文前面所述操作順序停止源和目標端各抽取及投遞進程（註意停源端抽取要驗證一下歸檔日誌是否存在防止無法重起），無需停止manager進程；
2) 修改目標表結構;
3) 修改源表結構;
4) 如果表有主鍵，並且本次修改未修改主鍵，則可以直接啟動源和目標所有進程繼續復制，完成本次修改；否則，如果表無主鍵或者本次修改了主鍵則需繼續執行下列步驟；
ggsci> dblogin userid goldengate, password XXXXXX
ggsci> delete trandata schema.mytable
ggsci> add trandata schema.mytable
（僅對Oracle 9i）如果表超過了32列則上述操作可能會報錯，此時需要手工進行處理，請參考附錄二如何手動為表刪除和增加附加日誌。
5) 重新啟動源端和目標端的抓取和復制進程。
（僅復制DML時）客戶應用的升級
如果是客戶的應用進行了升級，導致了源系統表的變化，在不配置DDL復制到情況下，需要對GoldenGate同步進程進行修改，可以參照以下步驟。
1) 停止源和目標端各抽取及投遞進程（註意停源端抽取要驗證一下歸檔日誌是否存在防止無法重起），無需停止manager進程；
2) 對源系統進行升級;
3) 在目標端將客戶升級應用所創立的存儲過程、表、function等操作再重新構建一遍。對業務表的增刪改等DML操作不必在目標端再執行，它們會被OGG復制過去;
4) 在目標端手工禁止建立的trigger和外鍵，並將這些sql以及反向維護的（即重新啟用trigger和外鍵）SQL添加到目標端OGG dirsql目錄下對應的腳本文件裏;
註意：在安裝實施時，應當將執行的禁止trigger和外鍵的表放到目標dirsql下，文件名建議為disableTrigger.sql和disableFK.sql。同時，需要準備一個反向維護（即重新啟用trigger和外鍵，建議為enableTrigger.sql和enableFK.sql）SQL，同樣放置到目標端OGG的dirsql目錄下，以備將來接管應用時重新啟用。
5) 對於升級過程中在源端增加的表，需要為新增的表添加附加日誌。步驟如下：
GGSCI 〉dblogin userid goldengate, password XXXXXXX
GGSCI > info trandata <schema>.<table name>
如果不是enable則需要手動加入：
GGSCI > add trandata <schema>.<table name>
註：（僅對Oracle 9i）如果該表有主鍵或者該表不超過32列，則顯示enabled表示添加成功；如果無主鍵並且列超過32列，則可能出現錯誤顯示無法添加則需要手工處理，此時請根據附錄二中方法手工處理。
6) 對於升級過程中在源端drop掉的表，GoldenGate缺省復制所有符合通配符條件的表，可以直接在目標端drop掉，無需對復制做任何修改；
7) 如果升級過程中修改了主鍵的表則需繼續執行下列步驟；
ggsci> dblogin userid goldengate, password XXXXXX
ggsci> delete trandata schema.mytable
ggsci> add trandata schema.mytable
（僅對Oracle 9i）如果表超過了32列則上述操作可能會報錯，此時需要手工進行處理，請參考附錄二如何手動為表刪除和增加附加日誌。
8) 重新啟動源端和目標端的抓取和復制進程。
配置DDL復制自動同步數據結構變更
是否打開DDL復制
對於OGG的DDL復制具體限制請參考附錄。鑒於這些限制，另外一個重要因素是DDL的trigger會對源庫性能帶來一定的影響，在國網原則上並不推薦DDL復制。如果有特殊理由需要打開DDL復制，可以與Oracle工程師予以協商。
打開DDL復制的步驟
以下內容為配置DDL復制的步驟，僅作參考，具體請參照GoldenGate的官方安裝文檔。
1) （可選，但強烈建議）定期收集數據字典統計信息，提高數據字典訪問速度
OGG的DDL復制需要大量訪問數據字典信息，通過數據庫定期收集統計信息（例如，每月一次），可以有效提高OGG DDL復制的性能。以下為一個例子:
sqlplus /nolog <<EOF
connect / as sysdba
alter session enable parallel dml;
execute dbms_stats.gather_schema_stats(‘CTAIS2‘,cascade=> TRUE);
execute dbms_stats.gather_schema_stats(‘SYS‘,cascade=> TRUE);
execute dbms_stats.gather_schema_stats(‘SYSTEM‘,cascade=> TRUE);
exit
EOF
2) 建立OGG復制用戶，或給現有用戶賦權限：
CREATE USER goldengate IDENTIFIED BY goldengate DEFAULT TABLESPACE ts_ogg;
GRANT CONNECT TO goldengate;
GRANT RESOURCE TO goldengate;
grant dba to goldengate;
3) 指定DDL對象所在的schema，這裏直接建立在goldengate用戶下：
Ggsci>EDIT PARAMS ./GLOBALS
GGSCHEMA goldengate
4) 檢查數據庫的recyclebin參數是否已關閉：
SQL> show parameter recyclebin
NAME TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
recyclebin string
on
如不是off，需要關閉recyclebin：
alter system set recyclebin=off
5) 建立OGG的DDL對象：
sqlplus "/ as sysdba"
SQL> @marker_setup.sql
Enter GoldenGate schema name:goldengate
SQL> @ddl_setup.sql
Enter GoldenGate schema name:goldengate
SQL> @role_setup.sql
Grant this role to each user assigned to the Extract, Replicat, GGSCI, and Manager processes, by using the following SQL command:
GRANT GGS_GGSUSER_ROLE TO <loggedUser>
where <loggedUser> is the user assigned to the GoldenGate processes.
註意這裏的提示：它需要你手工將這個GGS_GGSUSER_ROLE指定給你的extract所使用的數據庫用戶（即參數文件裏面通過userid指定的用戶），可以到sqlplus下執行類似的sql:
GRANT GGS_GGSUSER_ROLE TO ggs1;
這裏的ggs1是extract使用的用戶。如果你有多個extract，使用不同的數據庫用戶，則需要重述以上過程全部賦予GGS_GGSUSER_ROLE權限。
6) 啟動OGG DDL捕捉的trigger
在sqlplus裏面執行ddl_enable.sql腳本啟用ddl捕捉的trigger。
說明：ddl捕捉的trigger與OGG的extract進程是相互獨立的，它並不依賴於extract進程存在。即使OGG的extract進程不存在或者沒有啟動，但是trigger已經啟用了，那麽捕捉ddl的動作就一直延續下去。如想徹底停止捕捉DDL捕捉，需要執行下步禁用ddl的trigger。
7) （可選）安裝提高OGG DDL復制性能的工具
為了提供OGG的DDL復制的性能，可以將ddl_pin腳本加入到數據庫啟動的腳本後面，該腳本需要帶一個OGG的DDL用戶（即安裝DDL對象的用戶，本例中是goldengate）的參數:
SQL> @ddl_pin <DDL_user>
8) （如果不再需要DDL復制時）停止OGG DDL捕捉的trigger
在sqlplus裏面執行ddl_disable.sql腳本啟用ddl捕捉的trigger。
DDL復制的典型配置
GoldenGate的data pump進程和replicat的ddl開關默認是打開的，只有主extract是默認關閉的，所以DDL的配置一般只在主extract進行。 結合附錄所述的OGG的各種限制，如果需要打開DDL復制，則建議只打開跟數據有密切關系的表和index的DDL復制，參數如下：
DDL &
INCLUDE MAPPED OBJTYPE ‘table‘ &
INCLUDE MAPPED OBJTYPE ‘index‘
DDLOPTIONS ADDTRANDATA, NOCROSSRENAME
另外，在mgr裏面加入自動purge ddl中間表的參數：
userid goldengate,password XXXXX
PURGEDDLHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7
PURGEMARKERHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7
對於其它對象，依然建議使用手工維護的方式在兩端同時升級。要註意的是級聯刪除和trigger，在目標端建立後應當立即禁用。
GoldenGate 應用系統升級