truncate操作都将通过日志捕获并同步到目标数据库。
4.1.3.2 使用datapump
加入datapump后的数据传输的流程：
这里的datapump与ORACLE 10g推出的数据泵不是一个概念。在GoldenGate中，datapump相当于一个次级提取进程（secondary extract）。在上面演示的同步流程中，提取进程直接将提取的redo信息经过处理后放置到了目标端服务器上，当两者之间的网络出现故障时，会因无法生成trail文件而导致提取进程崩溃，错误提示类似如下：
2010-11-12 10:01:21 GGS ERROR 150 TCP/IP error 10061 (由于目标机器积极拒绝，无法连接。); retries exceeded.
2010-11-12 10:01:21 GGS ERROR 190 PROCESS ABENDING.
而加入datapump后，主提取进程（即第一个extract）首先将trail生成在本地，然后datapump读取本地trail再发送到目标服务器，即便网络故障，主提取进程仍然能随着事务生成trail文件，而datapump则会暂时停止传输，等待网络通畅后在将堆积的本地trail文件发送至目标服务器，从而实现了断点传输的功能。在实际应用中，每一个同步流程都应该配置datapump以应对网络问题。
加入datapump的配置： 将前面extl参数文件中的 /***
rmthost 192.168.0.44, mgrport 7801 rmttrail d:\\tools\\GG\\gg10g\\dirdat\\rl ***/ 替换为 /***
exttrail d:\\tools\\GG\\gg10g\\dirdat\\l1 --本地队列文件生成位置 ***/
专业资料
配置datapump进程：
GGSCI> ADD EXTRACT pump1, EXTTRAILSOURCE
extract pump1
userid ddw, password ddw
rmthost 192.168.0.44, mgrport 7801 rmttrail d:\\tools\\GG\\gg10g\\dirdat\\r1
PASSTHRU|NOPASSTHRU --直通模式或普通模式 gettruncates
table ddw.bbtest; ***/
直通模式用在两边表名、列名一致，可以直接映射的情况，不需要额外配置；普通模式可以配置表名列名自定义映射，可以加FILTER、transformation等，需要配置一个数据定义文件（data-definitions file）。
然后修改原先为提取进程配置远端队列位置：
GGSCI> delete rmttrail d:\\tools\\GG\\gg10g\\dirdat\\rl extract extl GGSCI> add rmttrail d:\\tools\\GG\\gg10g\\dirdat\\rl extract pump1 然后启动extl和pump进程就OK了。
4.1.3.3 使用数据定义文件
GoldenGate数据定义文件（data-definitions file），主要用于不同数据源之间（比如下面的Oracle与DB2之间的同步），进行数据同步时用来转换数据格式。数据定义文件主要包含表名、字段名、字段类型、字段长度和偏移量。
利用GoldenGate的defgen工具生成一个数据定义文件（data-definitions file），大致步骤如下：
（1）创建DEFGEN工具的参数文件
（2）运行DEFGEN工具生成数据定义文件 （3）配置GG进程识别定义文件
例子：
GGSCI> edit param defgen --创建DEFGEN工具的参数文件 /***
DEFSFILE
[{SOURCEDB | TARGETDB} 专业资料 ***/ 类似如下（ORACLE）： /*** DEFSFILE GG_HOME\\dirdef\\extdb.ref USERID ddw,PASSWORD ddw TABLE ddw.aatest; ***/ 然后退出GGSCI，在GG安装路径下运行DEFGEN工具： GG_HOME > defgen paramfile dirprm/defgen.prm 配置文件默认生成在GG_HOME\\dirdef下，不要去手动修改。如果对应表的表结构发生更改，需要重新生成这个配置文件。 然后将生成的配置文件拷贝至目标服务器的GG_HOME\\dirdef下。修改复制进程repl参数文件： GGSCI>edit param repl 将原先的assumetargetdefs参数替换为sourcedefs GG_HOME\\ dirdef\\extdb.ref GGSCI>stop repl GGSCI>start repl 数据定义文件的配置完成。 4.1.3.4 配置进程检查点（checkpoint） 检查点记录了进程读写的位置信息用以数据恢复，目的是为了防止进程因系统、网络崩溃而导致的数据丢失，对于GoldenGate保证数据同步过程中数据不丢失非常重要。GoldenGate的检查点由一个内部进程自动控制，与数据库检查点的概念类似。提取进程的检查点记录它在数据源中的读取位置和队列的写出位置，复制进程的检查点记录它读取队列的位置。每条提取或复制进程都有自己对应的检查点信息。当GoldenGate的进程重启时，由它所记录的检查点决定需要读取的队列位置。 GoldenGate的检查点信息有两种存放方式： （1）默认存放在GGHOME\\dirchk下的文件中，一个进程对应一个文件。提取进程只能使用这种模式。不需要特殊配置。 （2）存放在数据库指定的表中，需要进行如下配置： 首先在./globals参数文件中加入： /*** CHECKPOINTTABLE [ 然后运行： GGSCI> DBLOGIN [SOURCEDB GGSCI> ADD CHECKPOINTTABLE [ 专业资料 nodbcheckpoint，使用数据库记录检查点信息。 ORACLE官方文档中，比较推荐将复制进程的检查点信息存放到数据库表中进行管理，认为在某些情况下能促进数据恢复。并指出检查点信息量非常小，而且是进行记录更新而非记录插入，一个进程只对应一条记录，在它特殊的检查点处理机制下不会对数据库造成影响。个人猜想是当目标数据库崩溃还原后（特别是在不完全恢复的情况下），检查点信息能同数据库一起还原，在数据上能利用数据库事务性与数据库保持一致，从而在数据库正常打开后能继续进行数据同步。但实际上并不必要，因为数据库故障的情况多种多样，就算检查点同步恢复后，也不能保证直接就能启动GoldenGate进程。 4.1.3 ddl同步 GoldenGate的DDL同步只支持两边一致的数据库，限制条件较多（如不能进行字段映射、转换等），具体可以参考官方文档。DDL的抓取不是通过日志抓取来捕获的，而是通过触发器来实现，所以对源数据库的性能影响要比单纯的数据抓取要大很多，可谓屏弃了GoldenGate的优势。尽量不要使用GoldenGate的DDL复制功能，在大多数业务系统中，实际上不会有频繁的数据库结构变动，完全可以通过手工的方式进行维护。确实有大量DDL操作的环境，如果可以，还是推荐物理DG之类的替换方案；确实要使用GoldenGate的DDL复制，那么请详细参考官方文档的限制和说明。 --以上主要为个人意见，有不同看法的请无视 开启DDL复制的基本配置步骤为： （1）关闭ORACLE的回收站功能。 （2）选择一个数据库schema存放支持DDL的GoldenGate对象，运行相应创建脚本。 （3）编辑globals参数文件。 （4）修改extl和repl的配置文件 具体操作步骤： （1）关闭数据库回收站： SQL>alter system set recyclebin=off scope=both; （2）编辑globals参数文件： GGSCI>edit param ./globals 添加以下内容后保存： GGSCHEMA ddw --标明支持DDL的GG对象存放在哪个schema下 （3）执行创建脚本： 首先需要命令行进入GG安装目录下，然后再运行sqlplus执行脚本，如果不进入目录下脚本执行会报错（应该是由于GG脚本中子脚本嵌套使用相对路径的问题所造成）。 专业资料 --分析指定表生成配置文件
] --指定的检查点记录表 ***/
] --生成这个检查点记录表 在新增复制进程时可以在添加时指定checkpointtable [
]替代