ORACLE GoldenGate

GGSCI>edit param repl--配置复制进程参数 /***

replicat repl --复制进程名

userid ddw@orcl,password ddw --目标数据库的帐号密码 assumetargetdefs--两台数据库数据结构一致则使用此参数

reperror default,discard --如果复制数据出错则忽略

discardfile D:\\repsz.dsc,append,megabytes 100 --错误信息写入XXXX文件，追加模式，最大100m gettruncates --复制truncate操作

map ddw.aatest, target ddw.aatest_1; --映射关系，注意target前必须留一个空格 --map ddw.aatest, target ddw.aatest_1, keycols (name), where (TYPE1 = \

--加两横杠在配置文件中进行注释；keycols指定唯一键；where筛选数据

***/

开启复制进程： GGSCI>start repl

至此，一个最简单的同步配置完成，对于源数据库相应表的insert，update，delete和

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 , BEGIN

--即是对应extl配置文件中定义的d:\\tools\\GG\\gg10g\\dirdat\\l1

GGSCI> edit param pump1 /***

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 --指定由DEFGEN生成的数据定义文件的全路径和名称 [{SOURCEDB | TARGETDB} ,] --oracle不需要配置这个参数 [USERID [,PASSWORD ]] --DB2不需要配置PASSWORD TABLE .

--分析指定表生成配置文件 ***/

类似如下（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 ][, USERID [, PASSWORD ]] GGSCI>ADD CHECKPOINTTABLE [.

]--生成这个检查点记录表

在新增复制进程时可以在添加时指定checkpointtable [.

]替代nodbcheckpoint，使用数据库记录检查点信息。

ORACLE官方文档中，比较推荐将复制进程的检查点信息存放到数据库表中进行管理，认为在某些情况下能促进数据恢复。并指出检查点信息量非常小，而且是进行记录更新而非记录插入，一个进程只对应一条记录，在它特殊的检查点处理机制下不会对数据库造成影响。个人猜想是当目标数据库崩溃还原后（特别是在不完全恢复的情况下），检查点信息能同数据库一起还原，在数据上能利用数据库事务性与数据库保持一致，从而在数据库正常打开后能继续进行数据同步。但实际上并不必要，因为数据库故障的情况多种多样，就算检查点同步恢复后，也不能保证直接就能启动GoldenGate进程。

4.1.3 ddl同步

GoldenGate的DDL同步只支持两边一致的数据库，限制条件较多（如不能进行字段映射、转换等），具体可以参考官方文档。DDL的抓取不是通过日志抓取来捕获的，而是通过