发布时间 : 星期一 文章GoldenGate安装部署更新完毕开始阅读
为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 6.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参数批量应用，缩减了应用端的数据库压力和生成的日志大小。
41
7、GoldenGate推荐配置
这里的推荐配置并不一定是必须的，但往往是有益无害的，在正式项目环境中强烈推荐。很多配置都没有出现在我前面的例子中，一来是减小篇幅，简化案例的配置复杂度，二来我想放在这里集中介绍，可能效果会更好。 这部分内容将在后续继续补充完善。
7.1 添加必要的环境参数
建议在各Extract、DataPump、Replicat进程配置中加入部署环境的环境变量，以避免部署环境的复杂性带来影响。 特别是以下三个： /***
SETENV (NLS_LANG=\SETENV (ORACLE_HOME = \SETENV (ORACLE_SID = JIONG) ***/
7.2 BATCHSQL参数
GoldenGate的Replicat进程，根据接收到的trail文件生成SQL语句，然后在目标端执行这些SQL。为了提高执行效率，默认下这些SQL语句是分批提交的。Replicat SQL的执行方式有三种，如下图所示：
在Relicate中配置BATCHSQL参数，则可以使Relicate进程在可能的情况下，以BATCHSQL的模式在目标端执行SQL。在BATCHSQL模式下，Relicate进程组织相似的SQL放入数组中，然后一同执行。以这种模式应用SQL能减少目标端数据库的事务数，减少写GoldenGate检查点的次数并减小相应的I/O量，因此提升目标端Relicate进程的性能。
42
当然，并不是所有时候都会有相似的SQL可以组织到一起的，如果无法在BATCHSQL模式下执行，GoldenGate将会尝试普通模式（图中的normal mode，默认1000个事务提交一次），不会因为这个参数引起报错。所以推荐在Relicate配置中都加入这个参数的设置。 BATCHSQL配置示例：
/*** BATCHSQL OPSPERBATCH 2000 -- OPSPERBATCH表示一个BATCH最多包含多少行操作
***/ BATCHSQL可以指定子参数设置，也可以只配置一个BATCHSQL使用默认的子参数值。其他BATCHSQL子参数介绍请参看《Oracle GoldenGate Reference Guide》
7.3 数据库用户密码加密
由于GoldenGate所需的用户权限较大，而每个GoldenGate进程配置文件中都需要设置该用户和密码用于数据库登陆，出于安全性的考虑，强烈建议将密码进行加密。当然，如果已经采用了trail文件加密等其他加密级别更高的安全措施，那么这部分就没必要了。 加密方式如下：
（1）生成密钥 这步不是必须，也可以使用GoldenGate默认的密钥default，但是既然是为了安全性，推荐生成自己的密钥进行加密。
在GoldenGate安装目录下，keygen工具生成密钥：
GG_HOME> keygen 128 4 --128指密钥长度，最大128位；4表示生成4个密钥 然后将生成的密钥复制下来，新建个文本文档，拷贝进去，内容如下：
/***
mykey1 0x0D1E636569D147474B17DE700EB76B0E mykey2 0x1024106005B7DE2AF9765A768A49650F mykey3 0x132ABD5AA19C750EA7D6D67B06DC5E10 mykey4 0x16306A553C820C7256365301826E5811 ***/
这里的mykey1是自己定义的密钥逻辑名，用来一会调用时用，后面的一长串是刚才生成的密钥。将文本保存，注意文本名必须是ENCKEYS，大写，不带后缀。
然后将该密钥文本，放置在源端和目标端GoldenGate安装目录下。
（2）生成加密后的密码
在GGSCI接口命令行中对当前的数据库用户密码进行加密： GGSCI> encrypt password
这里的
命令执行后生成一串加密后的密码值，如：AACAAAAAAAAAAAFAYFVFUCAHOHDGIFWB
（3）应用加密密码 使用加密后的密码值，需要调整一下相应的参数：
43
/***
USERID ddw, PASSWORD <加密后的密码>, ENCRYPTKEY
如果是使用ASM实例的，则如下： /***
TRANLOGOPTIONS ASMUSER SYS@
想要立刻验证加密后的密码是否可用，可以用DBLOGIN命令测试：
GGSCI> dblogin userid ggdba,password <加密后的密码>, ENCRYPTKEY
7.4 trail再压缩
当数据进行异地传输时，网络负载是影响数据传输效率的关键因素。GoldenGate的其中一个优势是，它极大地压缩了传输的trail文件，通过前面的性能测试也可以看到，日志压缩比在3:1以上。但是如果传输事务量非常大的时候，这样的压缩比有时还是无法满足一般的网络负载要求。在默认压缩（redo=>trail）的基础上，GoldenGate提供了再压缩方案：在传输trail之前对其进行进一步的压缩，然后在写入远端trail之前再进行解压。官方文档中说明这次再压缩的压缩比至少在4:1，在我实际测试中差不多达到10:1。 注意GoldenGate的再压缩过程，由于在写入远端trail前已经经过了解压，所以单纯比较两端的trail文件大小会毫无觉察（我曾经一度以为该参数无效）。实际上借助流量监控工具可以监测到，传输同样大小的trail文件，再压缩方式的实际网络流量明显要小的多。这种方式的好处是对Replicat进程提取trail毫无影响，从而也避免了加重原本负载就相对较大的Replicat进程。 GoldenGate的再压缩，是在负责向远端发送trail的Extract进程中配置的，因此一般情况下都是配置在datapump中。配置很简单，在RMTHOST参数中加入COMPRESS子参数，如下： /*** rmthost 192.168.0.142, mgrport 7801, COMPRESS, COMPRESSTHRESHOLD 0
-- COMPRESS启用再压缩，COMPRESSTHRESHOLD表示对大于该值的trail记录块进行压缩，取值0到28000，默认1000，设置为0表示全部进行压缩
***/ 启用了压缩后，势必会消耗额外的CPU，在同步事务量较大的情况下，需要考虑CPU负载。但实际上在大部分的GoldenGate应用场景中，网络负载都远远大于CPU负载，启用trail再压缩的可能性还是很大的。用或是不用，取决于具体的部署环境很业务情况。
44