（仅复制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，在目标端建立后应当立即禁用。