GoldenGate安装部署及解决方案

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

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的抓取不是通过日志抓取来捕获的,而是通过触发器来实现,所以对源数据库的性能影响要比单纯的数据抓取要大很多,可谓屏弃了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脚本中子脚本嵌套使用相对路径的问题所造成)。

专业资料

联系客服:779662525#qq.com(#替换为@)