GoldenGate同步解决方案及性能测试

GoldenGate同步解决方案

及性能测试

目录

1、GoldenGate同步方案 ........................................................................................................ 2

1.1 使用GoldenGate初始化加载 .................................................................................. 2 1.2一对多数据同步（广播复制） ................................................................................. 4 1.3多对一数据同步（集中复制） ................................................................................. 5 1.4数据转换和过滤 ......................................................................................................... 6 1.5关于目标端高数据安全性下的GoldenGate配置方案.......................................... 10 1.6GoldenGate双向复制（active-active） ................................................................... 13 2、GoldenGate数据同步性能测试 ...................................................................................... 16

2.1 测试中主要监测数据和监测方式 .......................................................................... 16 2.2 测试脚本和GoldenGate配置 ................................................................................ 17 2.3 测试步骤 .................................................................................................................. 21 2.4 性能测试结果 .......................................................................................................... 23

1、GoldenGate同步方案

GoldenGate工具虽小，但它提供表级字段级同步映射，而且同步性能优异、资源消耗低，使它的灵活性很强，可以提供多种数据同步、冗灾的解决方案。

1.1 使用GoldenGate初始化加载

这里所指的GoldenGate初始化加载，只是它指提供的direct load方式，因为其他几种官方介绍的初始化方式要么需要借助其他数据库工具（如extract->SQL*Loader），要么中间走了完全没必要的步骤导致性能很差（如extract->file->replicat方式），都不算纯正的GoldenGate方式。 初始化加载架构：

上图中，显示了初始化加载启用了两条同步路线：上面一条是真正的initial load，负责将源数据端的数据一次性发送到目标数据库；下面一条，其实就是普通的GoldenGate同步进程，负责抓取初始化加载时源端数据库进行的在线数据变化。因为在实际应用中，往往需要在生产库（源数据库）不停机的状态下，将数据加载到备用数据库（目标数据库）中并应用实时同步，在数据初始化的过程中，生产库将继续进行正常的事务操作，所以此时需要有抓取进程在初始化时开始将这些变化捕获，以免数据丢失。

实际部署时需要注意正确的执行顺序，大致可以分为以下几步： （1） 源端和目标端创建配置各个同步进程。

（2） 开启源端同步抓取进程（图上的Change Extract），开始捕获变化。 （3） 开启初始化进程（图上的Initial-Load Extract），开始数据初始化加载。 （4） 等初始化加载结束，开启目标端复制应用进程（图上的Change Replicat），开始

实时同步应用。

在目标端复制应用进程（图上的Change Replicat）中，需要在参数文件中配置HANDLECOLLISIONS参数，以避免重复应用第2和第3步之间的数据变化，因为这部分数据已经包含在初始化加载中传到目标数据库中了。

在这里需要特别提醒的一个概念上的问题，GoldenGate的初始化同步不会也不需要去初始化目标端的SCN号。这个问题在我与多位数据库DBA的交流中发现，他们往往以为GoldenGate是通过SCN来判断数据的应用情况的。GoldenGate的同步与Streams不同，它不需要依赖两端数据库保持一致的SCN来应用同步，实际上它只在抓取时可能会与数据库的SCN有关联（抓取时可以指定源数据库的特定SCN号开始解析日志），在trail传输以及目标端应用时，都和源端数据库的SCN毫无关系。它的实质是通过自己的一套队列文件检查

2

点机制来实现队列数据的管理，在目标端则通过数据的唯一键来定位数据行，trail文件最终解析成SQL语句在目标端数据库执行而实现数据的应用。所以这里的初始化加载，完全可以使用其他数据库工具来实现，比如说exp/imp、SQL*Loader、RMAN复制数据库等。 以下为一个简单的初始化加载的例子，对于实时同步配置同上面介绍的是一样的，这里不再说明，只列出初始化加载部分的进程配置。

1.1.1 GoldenGate初始化加载示例（direct load方式）

源端

添加提取进程：

GGSCI> add extract ext1,sourceistable --没有tranlog,意味着不是通过日志方式；没有begin XXX，表示

还未启动；使用sourceistable参数不会使用检查点机制 配置文件如下： /***

extract ext1

userid ddw,password ddw

rmthost 192.168.0.44, mgrport 7401

rmttask replicat, group rept1 --注意是rmttask，指定目标复制进程名 table ddw.test; ***/

不需要为该进程添加远端队列（rmttrail）。

目标端

添加复制应用进程：

add replicat rept1,specialrun --表示一次性加载 /***

replicat rept1 assumetargetdefs

userid ddw,password ddw

reperror default, discard discardfile D:\\reptmy.dsc,append,megabytes 100 INSERTAPPEND--使用直接路径加载，提高加载速度

HANDLECOLLISIONS--当目标端已有数据时，略过重复数据错误 MAP ddw.test, TARGET ddw.test1; ***/

注意，这里的extract和replicat进程添加完后在info all中看不到这个进程，但是view report可以跟踪到。

要开始加载，在源端执行： GGSCI>start exttmy

3

目标端的replicat进程不需要去启动，会自动进行数据应用。

1.1.2 与Oracle数据泵数据加载速度的比较

按照5.6.1示例中的配置，对一张600万行数据的测试表进行初始化加载，完全加载结束大约需要50分钟。 使用Oracle 10g的数据泵工具对同样的表，通过DB Link的方式进行初始化加载：

C:\\>impdp ddw/ddw@orcl job_name=zhouimp tables=test CONTENT=DATA_ONLY network_link=\

只需要1分半钟就导完了600万行数据。两者的执行效率差别太大了。 所以在一般情况下，尽量使用其他高效的数据库传输工具来完成初始化加载，而不要用GoldenGate提高的初始化功能。

1.2一对多数据同步（广播复制）

一对多数据同步实现架构：

GoldenGate对于多对一的实现方式，就是对于同一个源建立多个提取进程同步进行，也就是说，对应不同的目标端，分别配置同步进程进行同步。配置过程与前面是一样的。

这里的多个目标端，有可能对应不同的数据库，也有可能是同一个库中的不同对象。如果是同步到同一个库中的不同对象，除了分别配置同步进程以外，有时候也可以在一个进程中完成，比如，可以在复制端如此配置： /***

4

REPLICAT rep146e1

USERID coss3,PASSWORD coss3 assumetargetdefs

REPERROR default,discard

DISCARDFILE d:\\ggoracle\\log\\rep146e1.dsc,append,megabytes 200 HANDLECOLLISIONS

MAP ddw.test, TARGET ddw.test1;

MAP ddw.test, TARGET ddw.test2;--同一张表同时对应多个表 MAP ddw.test, TARGET ddw.test3; ***/

当然，如果同步数据负载较大的情况下，还是建议在进程级别分开。

1.3多对一数据同步（集中复制）

多对一数据同步架构：

多对一数据同步实现方式同一对多，也是将extract-replicat将进程拆分成多个。 多对一同步需要注意的是，所有源端和目标端的表都应该使用一致的主键约束，而且在不同的源端不应该对同一键值的数据进行维护。也就是说，需要在业务上将不同源的数据隔离开来，以防止对同一数据的覆盖更改等问题。一般用于维护业务的区域性数据、然后统一同步到业务中心数据源的业务场景。 还有一个需要注意的方面是TRUCATE的捕获，在多对一的配置下应避免捕获。因为GoldenGate处理TRUNCATE同步是直接传输了这个语句，并不会提供具体删除的数据信息（没有REDO也无法提供），所以无论哪个源端执行了TRUNCATE，如果同步到了目标端，都会直接把目标端的表数据直接删光，无论目标数据是否是来源于这个源，造成数据的不一致。

5

1.4数据转换和过滤

GlodenGate中支持字段映射、数据筛选转换，以及调用执行数据库脚本或者SQL语句等，在一定条件下，甚至可以实现实时ETL的功能。

1.4.1 字段映射

GoldenGate中字段的映射一般配置在复制应用端的MAP参数中，字段映射要求两边尽量一致的字段的类型，当然也允许CHAR<->VARCHAR之类的转换。对于不同字段类型的映射，最好详细参考GoldenGate官方文档以得到足够的支持信息，并做好测试验证以防止数据丢失等。以下是字段映射的配置例子： 例子1： /***

MAP ddw.a1test, target ddw.a2test,--target前一定要留个空格，否则会报错 COLMAP(id = id, type1 = type1, sell_date1 = sell_date2);--字段映射配置 ***/

例子2： /***

MAP ddw.a1test, target ddw.a2test,

COLMAP(USEDEFAULTS, sell_date1 = sell_date2); --USEDEFAULTS表示自动映射同名字段 MAP ddw.a3test, target ddw.a4test; --不同的表映射，不同的map

MAP “ddw.a5test”, target “ddw.a6test”;--在有些大小写敏感的数据源需要引号区分大小写 ***/

例子3： /***

MAP ddw.a1test, target ddw.a2test,

COLMAP (USEDEFAULTS, num = 111, name = \@DATENOW()); --字段指定固定值，注意字符值加引号，数字值不可加引号；@DATENOW()表示当前系统时间 ***/

例子4： /***

MAP ddw.a1test, target ddw.a2test, COLMAP (USEDEFAULTS,

transaction_date =@DATE (“YYYY-MM-DD”, “YY”,YEAR, “MM”, MONTH, “DD”, DAY),);

--多个字符字段整合转换为目标端的一个时间字段

***/

在这里顺便插入一个很容易出错的表映射例子：

6

/***

map ddw.a*, target ddw.*; --通配符表示所有a开头的表进行映射，注意的是target后面的表名千万不

能也写成ddw.a*，不然会被映射成目标端aa开头的表 ***/

1.4.2 字段和数据筛选

GoldenGate中字段的筛选一般都在TABLE参数中配置（目标端是在MAP参数）。一般推荐在源端extract进程配置文件中配置，这样可以有效得减小trail文件的大小，减小网络负载。以下是一些筛选配置例子（只列出配置文件的TABLE参数部分）。

（1）字段筛选： /***

table ddw.aatest,

FETCHCOLS (id, name, type1, sell_date, value1);--表明只提取这些字段 ***/

使用指定字段做主键： /***

table ddw.aatest,

KEYCOLS (client_taq, id); ***/

（2）数据过滤： 使用WHERE条件： /***

table ddw.aatest, where (type1 = \--表明只提取表中type1=’1并type2=’2’的记录 ***/

如下提取非NULL值： /***

table ddw.aatest, where (value <>@NULL); ***/

使用FILTER参数： /***

table ddw.aatest, FILTER((num1*num2)>1000); ***/

与WHERE条件不同的是，FILTER只能后面数字，字符型需要转换后才可以使用，如： /***

7

table ddw.aatest, FILTER (@STRFIND(NAME, \***/

FILTER参数的优势是还可以指定只在某种DML操作下才过滤，比如： /***

table ddw.aatest, FILTER((ON UPDATE, ON DELETE, (num1*num2)>1000); --只在UPDATE和DELETE操作时过滤num1*num2不大于1000的值 ***/

1.4.3调用执行SQL或存储过程

在GlodenGate指令库中有个SQLEXEC指令，可以用来调用执行数据库存储过程或者自定义的SQL语句，可以指定输入参数，输出参数可以作为字段与目标表映射。使用这个指令，可以实现将源表做简单连接（table join）然后将连接后结果同步到目标表，达到简单的转换目的。

在复制端配置如下（以SQL为例，procedure是一样的，改成过程名即可）： /***

replicat repjoin

userid ddw,password ddw

sourcedefs d:\\tools\\GG\\gg10g\\dirdef\\extjo.ref reperror default,discard

discardfile D:\\repjoin.dsc,append,megabytes 100 gettruncates

mapddw.a1test, target ddw.a12test,

sqlexec (id testid,--自定义执行语句的唯一标识

query \ --:id_param为输入参数 params (id_param = NAME_ID)), --将输入参数指定为源表中某列 如果没有输入参数，则这部分改为NOPARAMS colmap (USEDEFAULTS, name = testid.name, value1 = testid.value1);

--新的字段映射，testid.name表示语句输出参数name

***/

上面的配置案例，实现了将ddw.a1test表中name_id字段通过字典表a2test转换为对应的真实name值，并增加了一个value字段，然后映射到ddw.a12test表中。ddw.a12test表中的记录实际就是前面ddw.a1test表和a2test表连接生成的记录。

但是，这里存在一个问题：字典表a2test是在源数据库呢，还是在目标数据库？显而易见，配置在复制进程的配置文件中，那条语句是在目标端数据库执行的（如果执行procedure那么这个过程也必须建立在目标端），字典表a2test在目标端（在我这个例子中）。而且同步是由表ddw.a1test上的事务触发的，字典表a2test中的数据无论怎么改都不会引起这个数据同步。这种情况下，可以考虑将字典表a2test也进行同步，来解决这个问题。

8

SQLEXEC指令也可以在提取进程中使用。如果有输出参数作为额外的映射列，这个时候需要将查询结果也一并传输过去。可以通过参数TOKENS进行传递，然后再在目标端映射。

以下对TOKENS的使用进行说明。

使用USER TOKENS AREA

可以使用TOKENS参数，在提取端将自定义的数据放入trail中，传递到目标端，映射到目标端的表中。这里针对前面SQLEXEC提出的问题示例。

提取端extract的TABLE配置： /***

TABLE ddw.test, sqlexec (id sqlid,

query \

TOKENS (TK_CODE = sqlid.codeid);--将提取端查询出的node_id字段值，标识为TK_CODE放入ddw.test

表的trail文件中，一起传递 ***/

目标端replicat的MAP配置： /***

MAP ddw.test, TARGET ddw.testother,

COLMAP (USEDEFAULTS,SITE_CODE = @TOKEN(\);--将TK_CODE值映射给目标字段 ***/

1.4.4 数据库DML操作过滤

数据库DML操作过滤，这里是指选择是否捕获INSERT、UPDATE、DELETE。在某些业务场景下，只需要捕获某一种特定的DML操作即可，比如业务数据库往数据仓库的数据同步，往往只需要捕获INSERT操作，而对于UPDATE、DELETE则不允许同步目标库。 默认下，INSERT、UPDATE、DELETE都是捕获的，可以分别在Extract进程的配置文件中加入IGNOREINSERTS、IGNOREUPDATES、IGNOREDELETES进行忽略。当然，在这种情况下，业务上需要做相应的限制。比如忽略DELETE操作时，源数据库应禁止重复插入DELETE掉的键值。 参数使用示例（表示只捕获INSERT）： /*** IGNOREUPDATES IGNOREDELETES ***/ TRUNCATE是一种特殊的删除操作，默认配置下GoldenGate不进行捕获，一般需要在Extract进程的配置文件中加入GETTRUNCATES来指定捕获。

9

1.5关于目标端高数据安全性下的GoldenGate配置方案

1.5.1 配置方案

因为GoldenGate的标准配置下，是通过源端抓取进程向目标端发送队列文件的方式传输数据的，但在实际应用中，会出现这么一个关于安全方面的问题：如果上级机器的安全策略不允许外网直接往里发送数据，如何进行数据同步配置？ GoldenGate是有提供一个由目标端主动“申请”源端进行数据传输的方式，以保证内外网不同安全域下的数据安全保障。 解决方案的体系架构如下：

主要是通过目标端一个额外的alias Extract进程，实现由目标端（可信任域）主动请求、向源端（未信任域）提供数据传输的连接的过程。

具体的驱动模式如下（翻译自官方文档，可能表述得不准确）： （1） 启动可信任域的alias Extract进程

（2） 可信任域的GGSCI向未信任域mgr主进程发送消息，以启动相应的passive Extract

进程。消息包含可信任域的主机名或IP，以及一个可信任域mgr主进程的端口号。

（3） 未信任域接受消息后，启动passive Extract进程，并打开一个可用的端口号。 （4） 未信任域mgr主进程将该端口号返回给可信任域的GGSCI。

（5） 可信任域的GGSCI向本地mgr主进程发送请求以启动Collector进程。

（6） 本地mgr启动Collector进程，通过未信任域提供的端口号对未信任域进行监听。 （7） Collector进程打开与未信任域passive Extract进程的连接。

（8） 同步数据通过连接从未信任域passive Extract进程传输到Collector进程，然后写入

本地trail，被Replicat进程应用。

这里未信任域的passive Extract进程，即是源端的data pump Extract进程，所以只需要

10

改动源端的data pump Extract进程、新增一个alias Extract进程即可（Collector进程由目标端mgr自动配置）。

1.5.2 配置案例

1．源端配置（146上）

（1）创建提取进程（与普通情况下完全一样） GGSCI>add extract exta,tranlog,begin now 配置文件exta.prm： /***

extract exta

SETENV (ORACLE_SID = ORCL)

userid COSS360,password COSS360 exttrail C:\\ggoracle\\dirdat\\ea dynamicresolution gettruncates

TABLE COSS360.per_test, keycols (sampletime, objectid); ***/

创建本地队列：

GGSCI>ADD EXTTRAIL C:\\ggoracle\\dirdat\\ea,extract exta

（2）pump进程（passive extract进程） 创建passive pump：

GGSCI>ADD EXTRACT pumpa, exttrailsource C:\\ggoracle\\dirdat\\ea, begin now, passive, desc \ --passive表示为passive extract process 配置文件pumpa.prm： /***

extract pumpa

userid COSS360,password COSS360

--rmthost 192.168.0.142, mgrport 7801--原先的rmthost需要被注释 RMTHOSTOPTIONS compress--passive extract专有参数 rmttrail D:\\ggoracle\\dirdat\\trail146\\ea NOPASSTHRU gettruncates

TABLE COSS360.per_test, keycols (sampletime, objectid); ***/

创建远端队列：

add rmttrail D:\\ggoracle\\dirdat\\trail146\\ea extract pumpa

2．目标端配置（142上） （1）添加aliad extract进程

11

alias Extract进程不需要配置文件 添加语法：

ADD EXTRACT

, RMTHOST { | } , {MGRPORT } | {PORT ] *, DESC “”+

此处测试的创建命令如下：

GGSCI>add extract ext146pa, rmthost 192.168.0.146, mgrport 7801, rmtname pumpa

--需要定义源端的地址、端口，而且如果alias extract名称和passive extract名称不同，需要特别指定rmtname

（2）添加应用进程（与普通情况下完全一样）

GGSCI>add replicat rep146ea exttrail D:\\ggoracle\\dirdat\\trail146\\ea,nodbcheckpoint

配置文件rep146ea.prm： /***

REPLICAT rep146ea

USERID coss3,PASSWORD coss3 assumetargetdefs

REPERROR default,discard

DISCARDFILE d:\\ggoracle\\log\\rep146ea.dsc,append,megabytes 200 gettruncates

HANDLECOLLISIONS

BATCHSQL BATCHESPERQUEUE 200, OPSPERBATCH 2000 MAP coss360.per_test, TARGET coss3.per_test, keycols (sampletime, objectid); ***/

3．同步进程的启动和关闭

注意，passive extract(这里是pumpa)不应该被手动启动（手动也无法启动）。在上面的进程创建和配置完成后，正确的启动方式如下： （1）源端start exta，目标端start rep146ea （2）目标端start ext146pa（alias Extract）

（3）在正确的配置下，pumpa会自动启动。Pumpa启动后，同步正常开始。 同样，进程关闭时，无论在源端关闭passive extract或是在目标端关闭alias extract，对应的alias extract和passive extract都会自动关闭。

12

1.6GoldenGate双向复制（active-active）

双向复制系统架构如下：

GoldenGate双向复制，意即两端数据库互为源数据，无论在哪一端上对业务数据进行操作，都将同步应用到另一端。

1.6.1 双向复制的注意点

1．防止数据循环 双向复制中，最主要的问题是需要防止数据的循环应用。在GoldenGate中，需要从两方面进行预防：

（1）防止Extract进程抓取Replicat进程的SQL操作。

在默认配置下，GoldenGate的Extract进程会忽略捕获由Replicat执行的SQL操作（Teradata除外，需要进行额外配置），所以这部分一般不需要额外设置。 （2）使Extract进程识别本地Replicat执行的DML事务，并进行忽略。 这步在Oracle（10g and later）中的配置为在Extract进程加入参数：

TRANLOGOPTIONS EXCLUDEUSER 进行排除。

不同的数据库这里需要配置的参数不同。如果是Oracle 9i或之前的版本，需要配置tracetable。

2．防止数据冲突 由于是双向复制，那么当两端都对同一数据进行操作时，就会发生冲突。比如同时对某行数据进行修改，修改的操作将会被覆盖（视LAG以及事务的先后）；又比如两端插入或删除相同键值的数据。 对于这类数据冲突，最好是在业务应用层解决。比如，可以划分两端数据库应用的业务范围，一部分数据只在一端修改维护，另一端则修改维护其他数据；在两端定义不同的键值生成策略；关注同步表上的触发器和on delete cascade约束。也可以借助GoldenGate的映射和过滤功能，对于两端同步的数据进行区分。 总之，在配置双向复制环境时，需要综合考虑当时业务情况，一般都需要在应用层进行适当的修改，以防止数据冲突带来的数据丢失和不一致。

13

1.6.2 双向配置示例

这个示例中，ggdba用户作为GoldenGate专用用户，ddw和ddws分别为两端数据库需要同步的schema（也可以同名，这里是为了便于区别），通过在两端Extract中配置排除ggdba的操作防止循环应用。以下ddw结尾的进程均在ddw用户所在数据库，ddws结尾的进程均在ddws用户所在数据库。

(1) ddw==>ddws

添加提取进程：

GGSCI> add extract extddw,tranlog,begin now /***

extract extddw userid ggdba,password ggdba exttrail E:\\ggoracle\\dirdat\\e1

tranlogoptions excludeuser ggdba--排除捕获ggdba dynamicresolution gettruncates TABLE ddw.*; ***/

GGSCI> add exttrail E:\\ggoracle\\dirdat\\e1, extract extddw

添加datapump：

GGSCI> add extract pumpddw,exttrailsource E:\\ggoracle\\dirdat\\e1,begin now /***

extract pumpddw

userid ggdba,password ggdba

rmthost 192.168.1.101, mgrport 7801 rmttrail E:\\ggoracle\\dirdat\\rep\\e1 PASSTHRU gettruncates table ddw.*; ***/

GGSCI> add rmttrail E:\\ggoracle\\dirdat\\rep\\e1, extract pumpddw

添加复制应用进程

GGSCI> add replicat repddws,exttrail E:\\ggoracle\\dirdat\\rep\\e1, nodbcheckpoint /***

replicat repddws userid ggdba,password ggdba ASSUMETARGETDEFS reperror default,discard

discardfile E:\\ggoracle\\log\\repddws.dsc,append,megabytes 200

14

gettruncates

HANDLECOLLISIONS

MAP ddw.*, TARGET ddws.*; ***/

(2) ddws==>ddw

添加提取进程：

GGSCI> add extract extddws,tranlog,begin now /***

extract extddws userid ggdba,password ggdba exttrail E:\\ggoracle\\dirdat\\e2

tranlogoptions excludeuser ggdba--排除捕获ggdba dynamicresolution gettruncates TABLE ddws.*; ***/

GGSCI> add exttrail E:\\ggoracle\\dirdat\\e2, extract extddws

添加datapump：

GGSCI> add extract pumpddws,exttrailsource E:\\ggoracle\\dirdat\\e2,begin now /***

extract pumpddws

userid ggdba,password ggdba

rmthost 192.168.1.101, mgrport 7801 rmttrail E:\\ggoracle\\dirdat\\rep\\e2 PASSTHRU gettruncates table ddws.*; ***/

GGSCI> add rmttrail E:\\ggoracle\\dirdat\\rep\\e2, extract pumpddws

添加复制应用进程：

GGSCI> add replicat repddw,exttrail E:\\ggoracle\\dirdat\\rep\\e2, nodbcheckpoint /***

replicat repddw userid ggdba,password ggdba ASSUMETARGETDEFS reperror default,discard

discardfile E:\\ggoracle\\log\\repddw.dsc,append,megabytes 200 gettruncates

HANDLECOLLISIONS

15

MAP ddws.*, TARGET ddw.*; ***/

开启所有进程，双向复制开始。

2、GoldenGate数据同步性能测试

这个GoldenGate同步性能测试，是在以前项目中，为测试该工具是否能满足实际项目中数据同步的实时性、高负载性，自己做的一次伪性能测试。 由于测试条件和个人能力所限，测试仅在局域网内的普通PC（实际为虚拟机上划分的两个OS环境）上进行；测试中的事务仅为单一简单语句（Insert），同步的表为一对一进行同步；测试中源端只提供了每秒5000多条的事务量，实际可以调整得更高些（当然受数据库性能制约），但在这个条件下峰值测试没有什么意义；GoldenGate的参数配置也不能满足最优化配置。

测试主要目的：

（1） 反映在这个条件下，实时同步大致的性能效率。 （2） 提出一个GoldenGate实时同步性能测试的方案。 （3） 提出实际项目部署中，需要考虑到哪些负载问题。

2.1 测试中主要监测数据和监测方式

（1）源端和目标端每秒提交数据量 测试数据生成时，以1秒为间隔统计2端端口性能表的数据量，记录在测试日志表GG_PERFORMANCE_TESTLOG中。

（2）测试过程中两端数据库生成的REDO量 测试前清空两端数据库的归档日志，测试后switch日志组，统计归档文件生成量。同时在测试中在线监测相关会话生成的REDO量。

（3）生成的测试数据在表空间中占用的空间大小 测试后分析per_test表进行空间大小统计。

（4）测试数据传输时生成的trail文件大小 关闭trail文件自动清除，比较测试前后相应trail队列的增长情况。

（5）记录测试时两端的网络流量情况 通过金山卫士的流量监控功能监控。同时在线监测replicat端的lag情况。

16

2.2 测试脚本和GoldenGate配置

同步性能测试在2个虚拟机之间进行，IP分别为192.168.0.146和192.168.0.142，由146向142同步数据，146上insert一条新记录作为一个事务提交。同步测试表为PER_TEST。

2.2.1 测试脚本

（1）DB Link

为监控方便，146上建立142的DB Link，主要为统计两边数据库提交的数据量，并不用于数据同步：

create database link DB142.REGRESS.RDBMS.DEV.US.ORACLE.COM connect to coss3 identified by coss3

using 'orcl142';--146上142数据库的服务名

（2）性能测试日志表

create table GG_PERFORMANCE_TESTLOG (

RECORD_DATE TIMESTAMP(6), COUNTS_142 NUMBER, COUNTS_146 NUMBER, DIFFERENCE NUMBER,

MARKS VARCHAR2(500) )

（3）测试数据生成脚本

CREATE OR REPLACE PROCEDURE P_GG_PERFORDATA( /*

* INSERT TEST DATA FOR TESTING GOLDENGATE SYNC PERFORMANCE DATA;

* THE USER WHO EXEC PROCEDURE P_GG_PERFORDATA NEEDS 'execute on dbms_lock' PRIVILEGE

* AUTHOR ZHOUJIONG 2011-04-07 */

p_looptime in pls_integer ) AS

v_date date; Begin

17

v_date:=sysdate; for i in 1..p_looptime loop

/** port performance data **/ insert into PER_TEST (sampletime, objectid, step,

OBTAINABLE,

PORT_IN_PKT_BROAD_SPEED, PORT_IN_PKT_DIS_SPEED, PORT_IN_PKT_ERR_SPEED, PORT_IN_PKT_MULTI_SPEED, PORT_IN_PKT_NUNI_SPEED, PORT_IN_PKT_UNI_SPEED, PORT_IN_SPEED,

PORT_OUT_PKT_BROAD_SPEED, PORT_OUT_PKT_DIS_SPEED, PORT_OUT_PKT_ERR_SPEED, PORT_OUT_PKT_MULTI_SPEED, PORT_OUT_PKT_NUNI_SPEED, PORT_OUT_PKT_UNI_SPEED, PORT_OUT_SPEED) values

(v_date, i, i,

'T', 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32); commit; end loop;

dbms_lock.sleep(600); --执行完毕后停顿10分钟，便于在线收集redo量

18

Exception

when others then

dbms_output.put_line(substr(SQLERRM, 1, 1000)); End P_GG_PERFORDATA;

（4）数据统计脚本

每秒统计142、146上端口性能表中已提交的数据量和差值。 CREATE OR REPLACE PROCEDURE P_GG_TESTLOG( /*

* COMPARE THE ROWS COUNTS BETWEEN 146 AND 142 FOR TESTING GOLDENGATE SYNC; * IT SHOULD BE CALLED BEFORE WHEN THE P_GG_PERFORDATA WILL BE CALLED * AUTHOR ZHOUJIONG 2011-04-07 */

p_marks in varchar2 default null --for marking which tests the records belong to ) AS

v_timestamp timestamp; v_rows_146 number:=0; v_rows_142 number:=0; begin

for i in 1..1200 loop

v_timestamp:=systimestamp; select (select count(*) from per_test) num1,

(select count(*) from per_test@DB142.REGRESS.RDBMS.DEV.US.ORACLE.COM) num2

into v_rows_146,v_rows_142 from dual;

insert into GG_PERFORMANCE_TESTLOG(RECORD_DATE,COUNTS_142,COUNTS_146,DIFFERENCE,MARKS) values (v_timestamp,

v_rows_142, v_rows_146, v_rows_146-v_rows_142,

p_marks); commit;

dbms_lock.sleep(1); end loop;

Exception

when others then

dbms_output.put_line(substr(SQLERRM, 1, 1000)); end P_GG_TESTLOG;

19

2.2.2 GoldenGate配置

为统计生成的trail文件量，首先将两端的mgr.rpm中的PURGEOLDEXTRACTS C参数注释掉，并重启mgr进程。

（1）146上extract进程配置 ext3.prm /***

extract ext3 SETENV (ORACLE_SID = ORCL)

userid COSS360,password COSS360 exttrail C:\\ggoracle\\dirdat\\e3 dynamicresolution gettruncates

TABLE COSS360.per_test, keycols (sampletime, objectid); ***/

pump3.prm /***

extract pump3

userid COSS360,password COSS360 rmthost 192.168.0.142, mgrport 7801 rmttrail D:\\ggoracle\\dirdat\\trail146\\e3 NOPASSTHRU gettruncates

table COSS360.res_p_s_*; ***/

（2）142上应用进程配置 rep146e3.prm /***

REPLICAT rep146e3

USERID coss3,PASSWORD coss3

--SOURCEDEFS d:\\ggoracle\\dirdef\\ext146\\ext3.ref assumetargetdefs

REPERROR default,discard

DISCARDFILE d:\\ggoracle\\log\\rep148e3.dsc,append,megabytes 200 gettruncates

20

HANDLECOLLISIONS

BATCHSQL BATCHESPERQUEUE 200, OPSPERBATCH 2000 MAP coss360.per_test, TARGET coss3.per_test, keycols (sampletime, objectid); ***/

2.3 测试步骤

（1）清空两端测试表

SQL>truncate table per_test;

（2）清空归档和日志

sqlplus sys/broada_plat@orcl142 as sysdba SQL> alter system switch logfile;

SQL>host RMAN target sys/broada_plat@orcl142 RMAN> delete noprompt archivelog all; RMAN> exit

SQL>conn sys/broada_plat@orcl146 as sysdba SQL> alter system switch logfile;

SQL> host RMAN target sys/broada_plat@orcl146 RMAN> delete archivelog all;

这里需要注意的是，extract进程应该在归档清空后开始抓取，即建立extract进程应该在这个时间点之后begin。主要了防止日志大小统计的不准确。

（3）开启两端GoldenGate进程，记录初始trail file大小 146：2K 142：2K

（4）执行测试脚本

分别在两个命令行窗口中执行2个脚本，其中p_gg_testlog提前于P_GG_PERFORDATA执行，以记录完整的测试信息：

SQL> exec p_gg_testlog(p_marks => 'one')

SQL> exec P_GG_PERFORDATA(p_looptime => 10000000);--实际执行时间约1882秒

（5）测试数据生成结束、会话未关闭时（即10分钟停顿时间内）数据监控 查看相应SESSION

146 user commit: 10000000次 142 user commit: 10082次

备注：在应用端配置了每1000条事务进行一次批量提交

21

会话REDO生成情况统计：

select s.sid, n.name, round(s.value / 1024 / 1024) \from v$sesstat s, v$statname n where s.statistic# = n.STATISTIC# and n.name like '%redo size%' order by 3 desc; 统计结果：

142上会话redo量（SID 288） ------------------------------------- 1 288 redo size 1679M

146上会话redo量（SID 211） ------------------------------------- 1 211 redo size 10037M

金山卫士流量监控中记录142总下载流量为3.1G。

GoldenGate应用端控制台中，查看lag信息，基本在3秒以内。

（6）统计表大小

SQL>analyze table per_test compute statistics; --190s左右

SQL>select s.segment_name,(s.bytes/1024)||'K' bytes from s.segment_name=UPPER('per_test');

146上

---------------------------------------------------------------- 1 PER_TEST 770048K

142上

---------------------------------------------------------------- 1 PER_TEST 770048K

两端的rows均为1000万行，传输中无数据丢失。

（7）检查trail文件大小 测试后trail文件大小：（e3*） 146：3,326,940,923 142：3,326,956,814

（8）检查生成的归档文件大小

sqlplus sys/broada_plat@orcl142 as sysdba SQL> alter system switch logfile;

sqlplus sys/broada_plat@orcl146 as sysdba SQL> alter system switch logfile;

user_segments s where 22

146：12,413,898,752 142：1,826,665,472

备注：146上的归档还包含一部分因日志表数据插入造成的归档数据。但在前面redo统计中则不包含，因为2个脚本分别运行，在不同的会话下。

（9）查看146上日志表

通过以下语句查看这次测试的日志表数据：

select * from gg_performance_testlog t where regexp_like(marks,'one') order by 1

日志表记录了同步过程中，两端同步表已提交数据的数量和差值，每秒记录一次。可以通过日志表的数据，计算出每秒事务量，并估算出同步效率。如果差值大，表明网络延迟较大；如果差值不断增大，表明应用端同步效率较低，无法满足源端的事务量。

另一文档《性能测试日志表数据》中记录了这次测试的日志表数据。

2.4 性能测试结果

2.4.1 测试数据计算

测试日志表中，记录了测试数据生成时间是从9:58:34到10:31:06，约32分32秒，生成1000万条测试记录，每生成一条记录提交一次，所以： 每秒事务量=10,000,000/1952=5123 次/秒

根据测试日志表记录，统计差值情况：

select avg(difference) avg,max(difference) max from gg_performance_testlog t where regexp_like(marks,'one')and difference>0; avg max

------------------------------------------ 17895.8988970588 51260

即同步时两端记录平均差值约17896行，最大差值为51260行。差值并不随着时间增大，表明应用进程的应用效率能满足抓取的每秒事务量。

146端在10:31:06完成所有事务，相应的，142端10:31:11完成所有应用，最终同步lag约5秒。 生成的trail文件大小3,326,956,814字节，约3172.8M或3.1G，与前面记录的网络传输流量3.1G基本一致，所以： 每秒网络传输流量=3172.8/1952=1.6M/s 源端1000万条记录，相应生成的redo为10037M，约9.80G；应用端同步生成的redo

23

为1679M，约1.64G。记录在表中的存储大小，两端均为752M。所以： 源端每秒日志量=10037/1952=5.1M/s 应用端每秒日志量=1679/1952=0.86M/s 每秒trail文件大小=3172.8/1952=1.6M/s GoldenGate传输压缩比=9.8:3.1=3.16:1 两端数据库日志比=10037:1679=5.98:1

比较如下： 总时间 事务完成时间 数据量 每秒事务量 数据存储大小 产生的REDO 每秒日志量 网络流量

源端 1952s 10:31:06 1000万行 5123次/s 752M 10037M 5.1M/s 1.6M/s 1679M 1.6M/s 目标端 10:31:11 TRAIL文件大小 3172.8M 2.4.2 测试结果

从上述测试数据中可得出：

（1） 源端每秒5123次事务，生成5.1M的日志；

（2） GoldenGate抽取压缩后每秒形成1.6M/s的trail文件，并通过网路传输到应用端； （3） 应用端应用每秒产生0.86M的日志，应用延迟约5秒。

从这次测试中，可以看出，实时同步，每秒5000次的事务量，在普通PC上的数据库即可满足应用端实时应用同步数据。同时每秒5000次的事务量会产生1.6M/s的网络流量负载，由于测试是在局域网内进行，在实际项目的实时同步中，要保证同步的实时性，就需要考虑到网络传输的能力，相对来说这一方面的压力可能会更大。GoldenGate可以再压缩传输的trail，同时可以借助BATCHSQL参数批量应用，缩减了应用端的数据库压力和生成的日志大小。

24

本文来源：https://www.bwwdw.com/article/tarh.html