平安集团Goldengate开发规范v10.docx
《平安集团Goldengate开发规范v10.docx》由会员分享，可在线阅读，更多相关《平安集团Goldengate开发规范v10.docx（57页珍藏版）》请在冰点文库上搜索。
平安集团Goldengate开发规范v10
中国平安保险（集团）股份有限公司
信息管理中心
项目编号
密级
秘密
修订历史
生效日期
版本号
版本说明
作者
审核
批准
2010/5/17
1.0
GoldenGate开发规范
Larry.zeng
2010/5/17
1.0
GoldenGate开发规范
Trent.rui
2010/5/17
1.0
GoldenGate开发规范
Martin.yang
GoldenGate开发规范
目录
1.引言5
1.1概述5
1.2术语和缩略语5
2.数据同步场景6
2.1同步功能支持6
2.2同步场景6
2.3单库对单库复制7
2.3.1数据复制中的负载均衡7
2.3.2单表到单表的同步8
2.3.3单表到多表的同步8
2.3.4多表到单表的同步9
2.3.5多表到多表的同步10
2.3.6数据过滤（Filter）规范10
3.架构设计规范10
3.1总体架构设计示例图10
3.2进程合并12
3.3进程拆分13
3.4多进程与数据一致性14
3.5架构优化设计方案15
4.命名规范（根据会议讨论结果，由平安自行拟定）17
4.1命名限制17
5.错误处理17
6.数据同步场景实现方法17
6.1单表数据同步到多表（同构）17
6.1.1需求场景17
6.1.2需求分析18
6.1.3Oracle建议方案模板18
6.2多表数据同步到单表（同构）18
6.2.1需求场景18
6.2.2需求分析19
6.2.3Oracle建议方案模板19
6.3路由功能20
6.3.1需求场景20
6.3.2需求分析20
6.3.3Oracle建议方案模板20
6.4表字段名称不一致的处理21
6.4.1需求场景21
6.4.2需求分析21
6.4.3Oracle建议方案模板21
6.5条件判断的处理22
6.5.1需求场景22
6.5.2需求分析22
6.5.3Oracle建议方案模板22
6.6RAC环境下Extract的配置22
7.OGG使用限制24
7.1源数据库的recyclebin24
7.2源端的LOGPARALLELISM24
7.3目标端的Trigger处理24
7.4目标端的CascadeDelete处理24
7.5物化视图处理25
8.MACRO的使用规范26
9.参数配置规范27
9.1参数配置原则27
9.2参数配置规范27
9.2.1事务完成性的保证27
9.2.2最大性能的保证27
9.2.3数据同步冲突的处理27
10.参数文件配置模版28
10.1GLOBALS参数配置28
10.2MGR进程配置28
10.3其它配置请参见寿险Elise数据同步参数配置模板28
11.参数文件代码书写规范28
12.与DataStage的使用场景区分29
附件1-寿险Elise数据同步参数配置30
同步场景30
数据同步配置文件中心库到机构库30
数据同步配置文件机构库到中心库41
附件2-GoldenGate对数据同步复制的支持44
数据库支持44
操作系统支持45
附件3-数据同步DML/DDL开发规范45
DML复制45
DML复制范围45
不支持文件等非结构化数据复制46
Oracle数据类型支持及限制46
OracleDML操作类型支持及限制46
DDL复制47
DDL复制适用场景47
DDL复制限制48
DDL复制的最佳实践48
参考文献49
数据同步参数配置文件说明手册
1.引言
概述
本开发规范用于在平安数据同步项目中,针对不同数据复制场景提供的参数配置模版.用于在数据同步中的规范性文档资料,该规范性文档包括参数配置的基本原则,OGG同步参数说明,针对不同场景的参数配置模版.
术语和缩略语
完整说法
缩略说法
1.
GoldenGate
GG
2.
JavaRumtimeEnvironment
JRE
3.
Extract
GoldenGate软件的抽取进程，又叫Capture进程，一般用于抽取数据库日志抓取数据变化或将本地队列中数据传递到目标端。
4.
Replicat
GoldenGate软件的投递进程，又称为Delivery进程，用于将队列文件中的数据变化转换为sql应用到目标库。
5.
DataPump
专指将本地队列中数据传递到目标端的Extract进程，区别于读取日志的主Extract进程。
6.
Trail
GoldenGate的队列文件，存储增删改等数据变化，以其专有格式存放。
注：
GoldenGate术语中把Capture和Datapump进程都叫做Extract进程，这是因为二者都负责把数据从一个地方抽取出来，放到另一个地方。
但是二者有根本的不同：
Capture进程负责将数据从日志中抽取到本地队列文件，而Datapump进程负责将数据从本地队列文件抽取到目标端队列文件。
本文中，提到Extract进程的地方，都包含了这两类进程；提到Capture和Datapump进程，则分别有所指代。
本文中的Delivery进程和Replicat进程则是同一回事。
2.数据同步场景
2.1同步功能支持
GG支持单库对单库，单库对多库，多库对单库，多库对多库的数据表复制功能.
GG支持数据表同步过程中的数据过滤,路由功能.
GG不支持在源或目标端的数据聚合操作,如sum,average,count等的数据复制
多表关联对单表的数据复制通过MV或View来实现,分两种情况:
1）实时数据同步，则所有数据需要初始化到目标端，在目标端建MV。
2）非实时数据同步，则在源端建MV（ondemand）汇总数据,GG同步MV的数据到目标端。
2.2同步场景
GG支持多种数据同步模式,数据库同步模式如下图所示,但任何一种复制模式都可以转换,分解为单库对单库的数据库同步模式.
2.3单库对单库复制
2.3.1数据复制中的负载均衡
性能的考虑
为了降低数据复制对源/目标端数据库的影响,可以采取如下措施:
1）源端数据库影响最小
在源数据库端不处理数据的路由,过滤.将该处理工作尽可能的转移到目标端的Datapump来完成。
2）目标端影响最小
在源数据库预先处理数据的路由,过滤.将处理后的数据传递到目标端。
空间的考虑
在一对多的数据复制场景中,由于多库的数据需要复制到一个库中,对数据复制所需的空间必须提前预留.可以采取如下措施:
1）在源端采取数据过滤来降低目标端的数据空间需求
2）在路由判断中,只复制满足条件的数据到目标端,既提前处理数据,只同步,复制满足条件的记录到目标端.
2.3.2单表到单表的同步
同步支持情况如下 :
NO
场景
分类
GG是否支持
实现方式
1
表结构相同
支持
mapping
2
表结构不同
字段类型不同
支持
GG转换函数
请参见6.4
3
字段数量不同
支持
Mapping
请参见6.4
4
字段名称不同
支持
Mapping
请参见6.4
5
过滤（通过本表字段）
支持
GG（filter）
请参见6.3
6
过滤（通过本地其它表关联查询）
支持
DPonsource
请参见2.2.5及6.3
7
源或目标端有聚合操作,如,group,average,sum等
不支持
2.3.3单表到多表的同步
可以拆分为”单表到单表”的同步来实现.请参见2.2.1,
主要分如下的同步场景:
NO
场景
分类
GG是否支持
实现方式
1
单表分解为多表（不同的字段到不同的表）
支持
Mapping
请参见6.1
2
单表复制到多表（相同的字段到不同的表）
支持
Mapping
请参见6.1
3
单表记录分发到不同的表中（根据条件不同，选择不同的记录到不同的表中）
支持
Mapping+where
请参见6.1,6.5
2.3.4多表到单表的同步
多表到单表的同步,除以下情形外,其它情形与2.2.1类似.
多表关联对单表的数据复制通过MV或View来实现,分两种情况:
1）实时数据同步，则所有数据需要初始化到目标端，在目标端建View或MV。
源端的所有数据需要初始化到目标端,采用GG保持数据变化的实时同步,所有的变换数据同步到目标端后,在目标端采用view或MV来进行数据的汇总及过滤
2）非实时数据同步，则在源端建MV（ondemand）汇总数据,GG同步MV的数据到目标端。
2.3.5多表到多表的同步
可以拆分为N个多表到单表的同步来解决,请参见2.2.3
2.3.6数据过滤（Filter）规范
1）不能出现Join
2）Filter的where只处理=，>=,<=,in,notin,like并且不能带任何函数，in和notin中只能是list.
3）Filter字段需要使用索引。
3.架构设计规范
3.1总体架构设计示例图
1）只有对于本机的复制（不经过中间网络）引入直接传输模式，即不使用DataPump。
例如，在一台主机上有多个业务系统，需要在各业务系统之间进行复制，可以按照直接传输模式（即没有DataPump的模式）设计链路；
2）只要复制需要通过中间网络，则需引入DataPump，通过DataPump进行数据传输。
3）目标端的datapump为可选,其目的是为了均衡数据同步负载或数据过滤。
如:
a）数据需要根据目标端的表进行过滤。
b）为了降低源端的路由判断对源数据库的影响,可以将路由判断移到目标端来完成。
4）如果有blob/clob同步的需求,必须使用专用的Extract进程,使之与其它进程区分开.
5）为了使数据同步对源数据库的影响降到最低,在源端的Extract进程,不能超过3个,Extract应该在Table级上。
3.2进程合并
1）进程根据需要同步的数据库分工来分工,一个数据库对应相应的extract、replicat,datapump
2）对于同一个数据库的同步,不允许多个replicat进程
在经过细分以后的结构图中，有时候一台主机上会出现多个同类进程，可以参照以下原则尝试合并：
Ø进程合并一般只针对于一对多的Extract合并；
Ø只能对于同一台主机上的同一个GoldenGate安装目录下进程进行合并；
Ø合并从主Extract进程开始，其原则为当向多个目标复制的数据集相同或大部分数据范围相同重叠时进行合并，否则无需合并；
Ø主Extract合并以后，本地队列自动随之合并；
ØDataPump根据源端的本地队列和目标主机的组合进行配置，一般无需合并；
ØReplicat进程根据传输到目标主机的队列个数进行配置，一般无需合并。
例如，上例中的一对二复制合并后为：
说明：
如果是对于多对一复制，Replicat进程是无法进行合并的，因为多个源过来的队列只能是多个队列，而一个Replicat只能处理一个队列。
例如，下列二对一复制例子中的Replicat无法合并：
3.3进程拆分
为了保证源端数据提交的顺序,在目标端严格顺序执行,原则上replicat进程不拆分
在进程合并后，可能因为性能问题需要进行进程拆分。
拆分的原则如下
Ø对于主Extract的拆分，一般可以遵循：
⏹如果源数据库日志产生量超过20G/小时，则考虑进行主Extract拆分；
⏹可以最繁忙阶段每小时日志量除以20G估算主Extract拆分的个数；
⏹主Extract拆分依次以Schema、Table、单个表的Range作为拆分依据，使各拆分出来的Extract负载均衡。
⏹主Extract拆分要考虑到事务一致性，即尽量将同一业务设计的表放在同一个Extract进程内。
ØDataPump无需拆分
ØReplicat拆分。
由于OGG的Replicat是单线程投递数据，一般均需进行拆分，以实现多线程并行工作，加快投递速度。
其拆分原则为：
⏹以投递性能作为拆分依据。
一般拆分数量需经过几次测试实验而得，建议按照表分配到多个进程，保证各进程间负载均衡；
⏹对于某些特大表，可以对单个表按照Range拆分为多个replicat进行处理；
⏹在拆分时，需要注意外键引用关系，保证有外键关系表在同一个进程。
如无法保证，则建议将目标的外键约束临时禁用，以后如需接管业务提前启用即可。
例如，上例中的一对二复制拆分后可能的结构图为：
3.4多进程与数据一致性
OracleGoldenGate进程之间是没有通讯机制的，为了保证数据的一致性，在设计结构的时候通过以下途径进行保证：
首先，将同一交易涉及的表划分在同一个进程组内，由于进程内部是完全保证交易一致性的，不会出现数据不一致情况；
其次，采用单一Extract和多个Replicat的模式。
由于Extract性能较高，一般客户源系统每小时不超过20G日志，可以在源端配置一个主Extract进程抽取所有的表，在抽取到队列时即可以保证交易一致性；而在目标端，通常为了性能考虑需要配置多个Replicat进程，它们之间可能存在临时的不同步，但是由于源端主Extract是单个的，所以目标端队列文件中的数据实际是保持了数据一致性的，在配置了足够Replicat后能够跟上队列产生的速度，此时各Replicat进程之间的时间差异一般会在1秒以内，只存在短暂差异。
而在接管业务时，可以等待若干秒时间等待所有Replicat把队列中数据应用完毕，此时目标库已经可以保证交易数据的完整性和一致性了。
由此可见，客户无需担心因为GoldenGate多进程并行处理带来交易数据不一致的问题。
3.5架构优化设计方案
1．尽量采用并行结构。
将事务量分配到多个并发执行的GoldenGate进程组上，以加快数据复制速度。
一个进程组包含一个Extract（抽取）进程，一个或多个Datapump（传输）进程，一个或多个Replicat（加载）进程，以及专供它们使用的Trail（队列）文件。
如图1所示。
2．预先估计各个表上的事务量，尽量将事务平均分配到不同的进程组上。
3．具有关联关系的表（例如，主外键），应被分配到同一个进程组，以保证事务完整性。
4．对一个Extract进程，应该使用多个Datapump进程，以充分利用网络的并发能力，快速将源端Trail文件传输到目标端。
如果Datapump进程没有做过滤和转换，则将其调整到PASSTHRU模式下运行。
5．对于目标端的每个Trail文件，建议使用一到两个Replicat进程并行加载。
具有关联关系的表应该放到同一个Replicat进程，以保证事务完整性。
6．单个GoldenGate实例上，并发进程数目不得超过200个。
如果系统内存较少（少于8G），则这个数目应该更小。
7．如果Extract进程抽取日志速度无法赶上日志产生速度的话，应该考虑对符合下列特征的表使用单独的进程组进行复制：
✓包含不能记录到事务日志的字段（如LOB、BFILE等字段）
✓事务特别繁忙
✓事务处理时间特别长
✓字段数目很多而且无法找到主键
8．如果Replicat进程加载速度无法赶上队列文件产生速度时，则应对该表进行行分割。
使用@RANGE函数，将一张表的不同行近似均匀的分配到多个GoldenGate进程组。
可以从Extract端进行分割，也可以从Replicat端进行。
建议从Extract端进行分割。
如图2示。
9．过滤和转换应该尽量使用Datapump或Replicat，而不是Extract。
如果源端不能受到太大的影响，则应该在目标端或单独的服务器上进行过滤和转换。
10．应将Trail文件分散到不同的磁盘上，以充分利用每个磁盘的IO性能。
对GoldenGate而言，RAID0+1比RAID5更加适合GoldenGate进程的IO需求。
图2行分割处理
4.命名规范（根据会议讨论结果，由平安自行拟定）
4.1命名限制
1）进程命名只能使用8位字符。
2）队列文件命名只能使用2位字符
5.错误处理
1）对于同步错误,所以的错误信息会放到系统配置的discard文件中.
2）错误的同步记录,除了防在discard文件中外,其相关信息还必须放在errortable中,errortable需要保持如下信息:
a.同步发生错误的表。
b.错误记录的标记,如pk,uk,或其它关键字段。
6.数据同步场景实现方法
上一章根据需求对于GoldenGate数据复制的总体拓扑和链路进行了设计，本章则进一步分析几个常用的数据同步场景。
不同数据同步场景中数据在源和目标两端的映射有着不同的需求，GoldenGate对于这些需求的满足是通过参数文件的中参数变化实现的，下面对于各种常见场景均举例予以说明。
6.1单表数据同步到多表（同构）
6.1.1需求场景
如GG_POL_AGT表的数据需要同步到表POL_BEN,POL_INSURED,POL_JNT_INSURED
6.1.2需求分析
OracleGoldenGate的数据同步是基于表级的,对于多表的到单表的同步需求,实质是也是通过单表到单表的同步来实现。
在对多表的同步中,表与表之间不能有聚合的函数操作,如（sum,average,…）。
6.1.3Oracle建议方案模板
配置参数涉及到Extract,Replicat的参数配置文档
Extract参数配置文件
TABLElifeman.GG_POL_AGT;
Replicat参数配置文件
MAPlifeman.GG_POL_AGT,TARGETELISDATA.POL_BEN;
MAPlifeman.GG_POL_AGT,TARGETELISDATA.POL_INSURED;
MAPlifeman.GG_POL_AGT,TARGETELISDATA.POL_JNT_INSURED;
6.2多表数据同步到单表（同构）
6.2.1需求场景
如上图所示,多表通过join后，需要将数据同步到单表
6.2.2需求分析
与6.2.2类似,同样不支持三级的父子嵌套关系。
6.2.3Oracle建议方案模板
配置参数涉及到Extract,Replicat的参数配置文档
Extract参数配置文件
TABLEELISDATA.CLIENT_BASE;
TABLEELISDATA.CLIENT_EXTEND;
TABLEELISDATA.SITE_TELEPHONE;
TABLEELISDATA.SITE_EMAIL;
TABLEELISDATA.SITE_ADDRESS;
Replicat参数配置文件
MAPELISDATA.CLIENT_BASE,TARGETLIFEDATA.client_info;
MAPELISDATA.CLIENT_EXTEND,TARGETLIFEDATA.client_info;
MAPELISDATA.SITE_TELEPHONE,TARGETLIFEDATA.client_info;
MAPELISDATA.SITE_EMAIL,TARGETLIFEDATA.client_info;
MAPELISDATA.SITE_ADDRESS,TARGETLIFEDATA.client_info;
MAPELISDATA.SITE_TELEPHONE,TARGETLIFEDATA.client_phone_info;
6.3路由功能
6.3.1需求场景
数据库A的数据需要根据不同的情况同步到数据库B,C。
数据的同步方向需要根据一定的判断条件来选择路由。
6.3.2需求分析
可以放在源端或目标端来完成,需要考虑到对数据同步性能的影响,目前建议在源端做基于字段值判断的路由,在目标端做基于SQL查询的路由。
6.3.3Oracle建议方案模板
如在目标端的DataPump进程,根据查询的结果判断数据是否需要复制到目标端
TABLEELISDATA.CLIENT_BASE,&
SQLEXEC（IDlookup1,&
QUERY"selectCLIENTNOconflictfromlifedata.client_infowhereCLIENTNO=:
client",&
PARAMS（client=CLIENTNO）,BEFOREFILTER,ERRORIGNORE,TRACEALL）,&
FILTER（@COLTEST（lookup1.conflict,PRESENT））,
说明:
SQLEXEC是路由判断的查询SQL语句,查询结果由FILTER进行判断,并确定路由的目标.
FILTER/PRESENT代表当记录存在时,就进行处理,否则记录就废弃
6.4表字段名称不一致的处理
6.4.1需求场景
如下所示:
源端表:
ELISDATA.CLIENT_EXTEND目标端表:
LIFEDATA.client_info
===============================================================
IDID
FIRSTNAMEPHONETICIZE_FIRSTNAME
LASTNAMEPHONETICIZE_LASTNAME
在源表的字段名称与目标端表的字段名称不一样,
6.4.2需求分析
建议平安在源/目标端的表字段名称一致。
如确有需要采用不同名称的字段名称。
处理方法是将字段名称的转换在目标端的Replicat进程来完成。
6.4.3Oracle建议方案模板
转换的模版如下所示如下:
源端表:
ELISDATA.CLIENT_EXTEND目标端表:
LIFEDATA.client_info
===============================================================
IDID
FIRSTNAMEPHONETICIZE_FIRSTNAME
LASTNAMEPHONETICIZE_LASTNAME
Replicat参数文件配置如下:
MAPELISDATA.CLIENT_EXTEND,TARGETLIFEDATA.client_info,&
colmap（usedefaults,
PHONETICIZE_LASTNAME=L
升级会员 