goldengate规范

2019独角兽企业重金招聘Python工程师标准>>>

1、概述#

目的与使用范围
GoldenGate实现数据库之间准实时数据同步。适用于业务系统之间的数据交换、分发，在线升级、迁移，准实时报表以及双业务中心（Active-Active）等应用。

2、GoldenGate规范范围#

本文档适用于科技需要使用GoldenGate工具进行数据库间数据同步的人员。以下就GoldenGate的使用规范及架构，安装和配置等方面进行详细说明。

3、GoldenGate安装部署规范#

规范一： 除Oracle到Oracle的同步外，暂不接受其他数据库的GG同步需求。

规范二： Golden Gate同步需求需要与DB架构师沟通确认可行性。Golden Gate环境搭建，包括软件安装和同步链路建立，由架构师负责协调和安排。
环境搭建完成时效不低于2周，实际时效视需求的复杂程度与DB架构师沟通确定。如果需要少于2周内完成搭建，需要申请例外。
GoldenGate环境搭建流程如下链接：GoldenGate环境搭建流程

规范三： GoldenGate的配置与调整（除了软件安装与同步链路建立）必须通过版本流程下发。
GoldenGate版本早于应用版本发布和应用上线，Golden Gate版本发布后并且观察同步正常后，再发布应用版本。DB架构师和开发DBA在接到Golden Gate项目或版本需求时，需要向SA和开发人员说明该要求，若不能按要求实现，开发人员需要申请例外。
在同步环境搭建完成的基础上，Golden Gate版本开发从接到SR需求到完成移交时效不低于1周，实际时效是需求复杂程度与DBA沟通确定。如果需要少于1周完成开发和移交，需要申请例外。
GoldenGate版本流程如下链接：GoldenGate版本流程图
GoldenGate版本部署说明模板如下链接：GoldenGate版本部署说明-模板

4、GoldenGate同步表规范#

规范四： GoldenGate只用于各个数据库之间准实时的数据传递,不允许除了列过滤以外的逻辑转换。不支持对源端dml操作用户的过滤。

规范五： GoldenGate同步表的进程创建使用标准模板进行修改，不允许添加和减少参数。

规范六： 源表和目标表的主键或者用于识别数据的唯一键必须存在，必须为ENABLE VALIDATE状态，并且必须一致。

规范七： 开发需提供源端同步表中数据情况，如果同步的源表中有数据则必须在同步目标表进行数据的初始化，保证源表和目标表初始数据一致。仅同步insert操作且不需要历史数据的情况除外。
已做GoldenGate同步的表增加同步字段，且该字段在源端已有数据，需要重新对目标表做数据初始化。

规范八： 源表和目标表的字段类型必须相同。

规范九： 源表字段的字节长度必须小于等于目标表字段的字节长度，如果源库和目标库的字符集不一样，则应考虑源库的字段长度转换到目标库的字符集后字段长度仍然能够容纳。
目数据库字符集有AL32UTF8和ZHS16GBK两种，ZHS16GBK存放中文占两个字节，AL32UTF8存放中文占三个字节。假如源端字符集为ZHS16GBK，
目标端字符集为AL32UTF8，如果源端字段长度为varchar2(20),则目标端字段长度应为varchar2(20)*3/2=varchar2(30)以使能够容纳源端数据。

规范十： 不允许lob，long，long raw等大字段类型的同步。

规范十一： 不允许进行DDL同步(truncate 可以按2.9申请例外)。如果DB版本部署DDL脚本，SA需咨询开发DBA该数据库的此表是否有进行GoldenGate同步。若做DDL操作的表有进行GoldenGate同步，则需提交GoldenGate的SR。

规范十二： 对于truncate操作，缺省不做同步；如果需要同步truncate，且满足目标端数据来源全部为GoldenGate的条件，可以申请例外。

通过GETTRUNCATES（同步）和IGNORETRUNCATES（不同步）参数控制是否进行truncate的同步。
在extract进程、pump进程和replicat进程的参数文件中配置此两参数。GETTRUNCATES参数后列出表为需要同步truncate；
IGNORETRUNCATES参数后列出的表为不需要同步truncate的表。
举例如下：
A库到B库的同步为例，A库为源，B库为目标，CHNLDATA.TABLE_1表需要同步truncate，参数文件中配置：

e_a.prm
extract e_a
obey ./direnv/db.oby
obey ./direnv/user.oby
tranlogoptions excludeuser ggmgr
exttrail ./dirdat/e0
table ggmgr.gg_send; GETTRUNCATES
table CHNLDATA.TABLE_1; IGNORETRUNCATES
table CHNLDATA.TABLE_2; d_b.prm
EXTRACT d_b
obey ./direnv/db.oby
obey ./direnv/user.oby
obey ./direnv/rmt_sales.oby
RMTTRAIL ./dirdat/d0
TABLE ggmgr.GG_SEND
GETTRUNCATES
TABLE CHNLDATA.TABLE_1 cols (col1,col2……); IGNORETRUNCATES
TABLE CHNLDATA.TABLE_2 cols (……); r_a.prm
REPLICAT r_a
obey ./direnv/db.oby
obey ./direnv/user.oby
SOURCEDEFS ./dirdef/sales.def CHECKPOINTSECS 30 GROUPTRANSOPS 20000 MAXTRANSOPS 30000 REPERROR DEFAULT, ABEND
DISCARDFILE ./dirrpt/r_sales.dsc, append, MEGABYTES 2000 DISCARDROLLOVER AT 05:30 ON friday
REPORTCOUNT EVERY 10000 RECORDS, RATE
WILDCARDRESOLVE DYNAMIC
ALLOWDUPTARGETMAP
map ggmgr.GG_SEND, TARGET ggmgr.GG_RECEIVE_R_A ,& colmap(... ...) ; GETTRUNCATES
map CHNLDATA.table_1, target getsdata.table_1 ,& colmap (…… ); IGNORETRUNCATES
map CHNLDATA.table_2, target getsdata.table_2 ,& colmap (…… );

规范十三： 对于单向的数据同步，除了2.11的情况，目标表不允许进行任何数据变更（包括Trigger、Delete Cascade或其它的DML操作）。
且在部署说明中写明需对目标表的dml操作进行审计，用以监控数据库用户对表的dml操作，打开审计及查询审计记录的方法见附件。
举例说明如下：如果源库A表插入一条数据同步到了目标库A表，之后目标库业务用户使用delete操作删除了A表这条记录，
当源库A表使用update操作更新这条记录并同步到目标库后，目标库A表因为已经删除记录就会更新出错，导致GG同步异常。

规范十四： 对于单向的数据同步，在目标端表中不是GoldenGate同步的字段且非主键字段，允许做修改，通过GoldenGate同步的字段不能进行任何形式的修改。目标端的表上需要增加trigger，限制修改GoldenGate同步的字段。
例如：源端表字段为（A,B,C），目标端表字段为(A,B,C,D)，两端主键字段为A，只有A,B,C字段通过Golden Gate同步，目标端的D字段允许业务进行修改。
限制修改目标表同步字段的trigger模板如下：

CREATE OR REPLACE TRIGGER TR_U_table_x BEFORE  UPDATE OF a,b,c ON schema.table_x
FOR EACH ROW BEGIN   IF     (   :NEW.a <> :OLD.a 
          OR :NEW.b <> :OLD.b 
          OR :NEW.c <> :OLD.c ）      AND (upper(user)<>'GGMGR')   THEN
     RAISE_APPLICATION_ERROR(-20000,'不能对单向同步的目标表进行数据修改操作。');   end if; END; /

规范十五： 不允许表级的双向同步。对于传递多级后形成的双向同步也禁止。
多级同步举例如下图：

例如：Tab1表从数据库A同步到数据库B的Tab2, 由于不再进行tranlogoptions excludeuser ggmgr与tracetable的控制，
在数据库B的抽取进程会将在Tab2上的所有的dml操作(包含在Tab2表上的application operation与来自于数据库A的Tab1的replicat operation)
都进行抽取，并发送到下游端C。数据库C也会进行类似的操作，将在Tab3上的所有dml操作同步到数据库A。
此时我们会发现在A端触发的dml操作经过B、C后又会重新传递到A端，形成死循环。
虽然在A与C之间没有直接的链路关系，但是存在间接的链路同步，因此会导致在这个闭合链路中出现循环同步。因此对于多级的反向同步也是禁止的。

规范十六： 不建议进行表级的级联同步。如果要进行表级的级联同步，需要提供原因进行申请。申请获批实施表级级联同步的情况下，“禁止出现传递多级后的双向同步”的原则是必须遵守的。
① 级联同步指如下的同步：
级联同步如下图所示：

② 禁止传递多级后的双向同步的原因分析与示例请参看2.12。

规范十七： 在目标库的replicat进程参数文件中必须列出所有同步字段的对应关系。不能使用usedefaults参数。因为usedefaults参数会按字段名默认匹配源和目标表，如果字段名不一致或做了修改会造成同步出错。
符合规范：

MAP NETS2DATA.T_PUB_TASK, TARGET NETSPLATDATA.T_PUB_TASK, & colmap (    SALES_RESULT_STATUS = SALES_RESULT_STATUS,             APPOINT_START_TIME = APPOINT_START_TIME,             APPOINT_END_TIME = APPOINT_END_TIME,             BEFORE_APPOINT_PRIORITY = BEFORE_APPOINT_PRIORITY,             AFTER_APPOINT_PRIORITY = AFTER_APPOINT_PRIORITY,             IN_APPOINT_PRIORITY = IN_APPOINT_PRIORITY,             IS_QUOTED = IS_QUOTED,             POLICY_END_DATE = POLICY_END_DATE );

不符合规范：
例1：

MAP NETS2DATA.T_PUB_TASK, TARGET NETSPLATDATA.T_PUB_TASK;

例2：

MAP NETS2DATA.T_PUB_TASK, TARGET NETSPLATDATA.T_PUB_TASK, & colmap (    usedefaults, SALES_RESULT_STATUS = SALES_RESULT_STATUS,             APPOINT_START_TIME = APPOINT_START_TIME,             APPOINT_END_TIME = APPOINT_END_TIME,             BEFORE_APPOINT_PRIORITY = BEFORE_APPOINT_PRIORITY,             AFTER_APPOINT_PRIORITY = AFTER_APPOINT_PRIORITY,             IN_APPOINT_PRIORITY = IN_APPOINT_PRIORITY,             IS_QUOTED = IS_QUOTED,             POLICY_END_DATE = POLICY_END_DATE );

规范十八： 禁止进行“行过滤”的同步。

禁止行过滤的原因举例说明如下：

原因一、导致GG新需求关联影响评估极复杂且不可控，未评估到的影响会造成该表在其他链路的原有同步在目标库产生不必要的update操作，增加目标库负载，引发性能问题。

• Luqd0中源表：table1（pk_col,col2,col3,col4,col5,channel_mode）,其中pk_col为主键。
  
• 2011年1月1日新建luqd0到elis的GG链路，实现table1表的部分字段的同步。该表的trandata信息为pk_col。此时同步没有问题。
  

• 2011年10月1日新建luqd0到cris的GG链路，同步table1表上channel_mode=’D01’的数据到cris库，为保证channel_mode字段始终能够获取value，需将channel_mode加入luqd0端GG的trandata设置中。假设源端channel_mode的值不会被修改。此时同步没有问题。
  

• 2012年1月10日源表table1新增非GG同步列col5。当修改col5时，因为trailfile中始终记录了channel_mode的value，在elis端会产生多余的update sql，导致elis数据库负载增加：
  

update table2 
set channel_mode=channel_mode的原值 where PK_COL= :B1;

到cris的链路，由于在r进程中配置keycols（pk_col,channel_mode）,同步暂时没有问题。

• 2012年3月又新增luqd0àmdm同步链路：
  
  • （1）对table1进行WHERE col3=’F’的过滤，则又需调整luqd0端的trandata配置(补充col3)。
    
  • （2）只同步pk_col，col2字段--属于部分字段同步。
    
  • （3）在r进程中对mdm端的目标表table_mdm写入常量:lbs_source=’luqd0’。
    

当在luqd0库中修改col4，col5字段时，会在mdm端产生无用update语句：

update table4 
set channel_mode=channel_mode的原值,col3=col3的原值,lbs_source=’luqd0’ where pk_col=:B1;

此时再回顾elis端的情况，发现不必要的update 语句发生了变化：

update table2 
       set channel_mode=channel_mode的原值 ,col3=col3的原值 where pk_col=:B1

同样的问题在cris也存在。

从上面的案例看出，纳入行过滤会导致trandata信息的新增，对于只同步部分字段的表会产生多余sql的执行，从而增加目标库的负载，引发性能问题。如果要避免这种问题，任何变更，包括但不限于源表新增字段，某条GG链路新增或删除同步字段，新增或删除该表的同步，新增或删除filter条件等，都会导致原有正常同步的链路需要重新评估关联影响，评估范围广，难度高，极易遗漏。对于识别出的关联影响，需要同步修改GG同步参数文件配置，使配置变得相当复杂难于理解。

原因二、如果filter字段值被修改，会导致同步数据错误，目标数据与源不一致：

综合以上分析，我们禁止在GOLDENGATE中进行“行过滤”同步。

规范十九： 对于DML操作类型的过滤，可以只进行insert的同步，或者insert、update、delete都同步，不允许仅同步update或delete操作。如果只做insert类型的同步，且不需要历史数据，那么可以不对目标表做数据初始化。

说明：对于仅同步insert操作，目标表不要求一定有清理机制。而且仅同步insert操作时，若源端进行数据删除操作，而目标端没有实施该同步删除动作，
当在源端插入符合主键唯一键约束的数据，同步到目标端引发目标端主键或唯一键约束问题，因此源端主键、唯一键生成必须避免与历史数据相同的情况产生。
如下只同步insert操作的配置符合规范：

IGNOREDELETES
IGNOREUPDATES 
TABLE ggmgr.GG_SEND; GETDELETES
GETUPDATES

如下只过滤了insert操作，不符合规范：

IGNOREINSERTS
TABLE ggmgr.GG_SEND; GETINSERTS

规范二十： 对于源库DB版本为oracle9i的数据库，不能在源库端对同步表进行direct-load INSERTs (例如insert /*+ append*/，sql*loader)
因为通过direct-load INSERTs插入的数据是无法被GG抓取的，而在10g以上版本（包含10g）中是可以进行此种操作的。

5、GoldenGate架构规范#

规范二十一： Golden Gate在源端使用一个EXTRACT进程，并在源端为每个目标端建立一个DATAPUMP进程，在目标端，为每一个源端建立一个REPLICAT进程。

为避免源端GG进程过多造成管理困难及给源端主机造成压力，使用一个Extract进程抽取源端同步表。为减低相同源端不同目标端GG维护的相互影响及数据过滤和分发的需要，在源端为每个目标端建立一个datapump进程将数据分发到各目标端，每个目标端建立一个REPLICAT进程将数据apply到目标数据库中。

说明：源库同步表的结构变更或同步表的数量增减因需要暂停Extract 进程，会造成所有目标端同步延迟。目标数据库端的变化可能会暂停源数据库端相应的datapump进程，但是不能影响同个源端到其他目标端数据库的同步。

规范二十二： 对于filter过滤必须使用源端的Datapump进程，不能使用Extract和replicat进程。

规范二十三： 对于同步环境相关的参数，需要单独配置在oby文件中，不能配置在进程的prm参数文件中，每个obey文件包含的信息如下：
db.oby：在源和目标端配置，设置同步的源和目标数据库sid
user.oby：在源和目标端配置，设置Golden Gate使用的源和目标数据库用户名密码
rmt_to_TargetSid.oby：在源端设置，同步到目标库的IP和GG端口db_SourceSid_lang.oby：在目标端设置，设置源端数据库字符集，在目标端的R进程参数文件用引用，注意对该oby文件的引用需要在user.oby之前，否则设置将不会生效。详细请参见参数文件模板。

数据库环境分为开发、测试、生产，三套环境的以上信息不同，并且以上信息设置好之后，不会随着GG版本的变化而变化，是固定的值。
因此，为了避免每次版本中配置这些环境信息而造成的误修改，需要将这些环境信息从prm参数文件中分离出来，分别写入不同的oby文件中。
参考附录GGoby.rar。

规范二十四： 单个数据库主机上，replicat进程总数不能超过主机CPU数量。

规范二十五： 当使用GG版本11.x时，需要在GG manager参数中配置syslog none，使gg日志不写入操作系统的syslog。当使用GG版本11.x以下时，需要请系统管理员在syslog.conf文件中配置user.none选项，使gg日志不写入syslog。

规范二十六： GoldenGate版本控制
对于9i版本的数据库，统一安装OGG 10.4版本。
对于10g及以上的数据库，统一安装OGG 11.1.1.1 (三个.1) 版本。
10g及以上数据库，不能安装OGG 11.1.1.1 (三个.1) 版本的情况，需要向数据库技术支持部部门长申请例外（包括OGG 11 + 以上不支持HP-UX PA RISC 11.11的情况。）
GoldenGate版本适用范围请参见如下链接：GoldenGate版本适用范围

规范二十七： 新的Golden Gate安装大版本、小版本号均需使用最高版。目前需要安装OGG 11.1.1.1版（个别平台和DB版本不支持除外）。
在主机director-dvp.app.paic.com.cn的/wls/paic/host_name/soft/oddirect/goldengate_version_11_1_1_1目录下寻找对应的操作系统和数据库版本GG安装介质下载。

6、GoldenGate优化规范#

如果已有配置不能满足GoldenGate同步的性能要求，则可以选用如下的优化方案。
规范二十八： 在目标数据库端对不能满足性能的表单独建立replicat进程进行同步。
如果源端同步表有大批量数据修改，在目标端可能会造成较大延迟，因此需在目标端单独建立replicat。
注意：具有关联关系的表(例如，主外键)，应被分配到同一个replicat进程，以保证事务完整性。

规范二十九： 在目标数据库端的replicat进程中添加如下参数：BATCHSQL BATCHESPERQUEUE 50, OPSPERBATCH 1200
BATCHSQL使Replicat进程将相似的SQL合并到一个队列中，对数据库一次提交。提高目标端同步性能。只适用于小表，对于列特别多或者字段特别长的表可能降低性能。
BATCHESPERQUEUE：控制内存队列中可以包含batches的最大数量，当达到BATCHESPERQUEUE的值时，目标端事务被执行。
OPSPERBATCH：设置一个batch能够包含的行操作的最大数量，当达到OPSPERBATCH的值时，目标端事务被执行。

7、GoldenGate安装规范#

规范三十： Golden Gate使用主机的Oracle用户进行安装。一个数据库只能安装一套Golden Gate软件，软件安装空间大小申请10G。
安装路径为：/paic/app/<$ORACLE_SID>/goldengate
在/paic/app/<$ORACLE_SID>/卷下创建Golden Gate目录 mkdir goldengate，在新建目录解压相应Golden Gate安装版本的压缩包 gzip –d *.gz 或者tar -xvf *.tar
对于在使用ZFS文件系统的主机上安装Golden Gate，由于zpool创建的时候会设置一个mount 点，后续再创建ZFS的时候mount点固定是zpool mount点的一个子目录，不能新建/paic/app/<$ORACLE_SID>的mount 点，因此这时要建立link，从zpool mount点的子目录下链接到/paic/app/<$ORACLE_SID>/goldengate目录。

规范三十一： GoldenGate在三套环境中各安装一套，如果测试环境有多个，安装在常规版本的测试库上。

规范三十二： 对于生产环境，由于Golden Gate在同步过程中需要在/paic/app/<$ORACLE_SID>/goldengate存放生成的trail file，该空间的大小按如下方法进行计算：
对于部分表同步，取公式一和公式二中较小的一个值。
对于全库的同步，取公式一计算的结果。
公式一：(30天的redosize之和/30 *5*1/3)*1.25：
说明：
①取30天数据是因为业务以三十天为一个业务周期，业务时间段指业务工作的时间，一般是从早上8到晚上6点，具体的系统可能会有差异，可以请运营提供相关信息
②1/3是因为trail文件的大小是日志文件大小的1/3。
③全库同步目标端所需空间大小与源端相同。
公式二：（在统计信息准确的条件下）
源端计算公式为：
每张表生成trail file的大小Size= (((INSERT_NUMBER*(sum(AVG_COL_LEN)+100) + DELETE_NUMBER*（PK_LENGTH +100）+ UPDATE_NUMBER*(sum(AVG_COL_LEN)+100) *0.5)/analyze_days)*5)
源端所需空间总大小为：各个同步表大小的加和 * 1.25。 公式说明：INSERT_NUMBER、DELETE_NUMBER、UPDATE_NUMBER为自上次收集统计信息以来表中插入数据、删除数据和修改数据的量，从sys.Dba_Tab_Modifications数据字典中获得。
AVG_COL_LEN为表中每列的平均长度，从dba_tab_columns数据字典中获得。
PK_LENGTH为表中主键的平均长度，从dba_tab_columns数据字段中获得。
analyze_days为自上次收集统计信息以来到目前相隔的天数。
每一个目标端计算公式为：
同步到目标端每张表trail file的大小Size=((INSERT_NUMBER*(sum(AVG_COL_LEN)+100) + DELETE_NUMBER*（PK_LENGTH +100）+ UPDATE_NUMBER*(sum(AVG_COL_LEN)+100) *0.5)/analyze_days)*5
目标端所需总大小为：同步到目标端各个同步表大小的加和 * 1.25。 公式中变量含义与源端公式含义相同。

规范三十三： GoldenGate同步需要主机端口进行文件传输，每一个Golden Gate传输进程需要一个传输端口。在主机上划分7809-7909供Golden Gate使用。
同一台主机的不同GoldenGate软件使用的端口不能相同。

规范三十四： GoldenGate同步需要创建数据库用户，用于执行同步的sql和验证数据库连通性等。数据库用户命名为ggmgr，使用dbadata表空间。连通性测试需在源端建表ggmgr. GGMGR.GG_SEND，目标端针对每个R进程建表GGMGR.GG_RECEIVE_<目标端R进程名>。
ggmgr用户及表创建请见附录脚本GGMGR.sql。

8、GoldenGate配置#

规范三十五： GoldenGate参数文件的配置，请参考附录参数文件模板。

规范三十六： trandata用于添加表的附加日志，在日志中记入表的主键信息，如果没有添加表的trandata，则update操作不能正常同步，只能在表级进行trandata，不允许对字段进行trandata。

规范三十七： GoldenGate的专用数据库用户ggmgr，密码需要密文配置在GoldenGate user.oby文件中，并且需要在版本下发过程中定期修改密码。具体操作方法参见GoldenGate安装手册和版本部署手册。

9、GoldenGate运营监控#

生产环境的Golden Gate由Golden Gate Director 来做日常的监控，具体监控由运维制定。

10、附录#

Golden Gate同步延时与一个事务中处理的行数有关，一个事务中处理的行数越多延时越大。以50万记录一次commit为例，Golden Gate同步延时测试数据参考如下：

转载于:https://my.oschina.net/u/729507/blog/88735