GoldenGate开发规范

GoldenGate术语

Extract：GoldenGate软件的抽取进程，又叫Capture进程，一般用于抽取数据库日志抓取数据变化或将本地队列中数据传递到目标端。
Replicat：GoldenGate软件的投递进程，又称为Delivery进程，用于将队列文件中的数据变化转换为sql应用到目标库。
Data Pump：专指将本地队列中数据传递到目标端的Extract进程，区别于读取日志的主Extract进程。
Trail：GoldenGate的队列文件，存储增删改等数据变化，以其专有格式存放。

注： GoldenGate术语中把Capture和Datapump进程都叫做Extract进程，这是因为二者都负责把数据从一个地方抽取出来，放到另一个地方。但是二者有根本的不同：Capture进程负责将数据从日志中抽取到本地队列文件，而Datapump进程负责将数据从本地队列文件抽取到目标端队列文件。本文中，提到Extract进程的地方，都包含了这两类进程；提到Capture和Datapump进程，则分别有所指代。本文中的Delivery进程和Replicat进程则是同一回事。

 

数据同步场景
     同步功能支持
    GoldenGate支持单库对单库，单库对多库，多库对单库，多库对多库的数据表复制功能.
    GoldenGate支持数据表同步过程中的数据过滤,路由功能.
    GoldenGate不支持在源或目标端的数据聚合操作,如sum,average,count等的数据复制

    同步场景
     GoldenGate支持多种数据同步模式,数据库同步模式如下图所示, 但任何一种复制模式都可以转换,分解为单库对单库的数据库同步模式.

 

  单库对单库复制
   数据复制中的负载均衡
   性能的考虑
          为了降低数据复制对源/目标端数据库的影响, 可以采取如下措施:
      1) 源端数据库影响最小
          在源数据库端不处理数据的路由,过滤. 将该处理工作尽可能的转移到目标端的Datapump来完成。 
      2) 目标端影响最小
        在源数据库预先处理数据的路由,过滤. 将处理后的数据传递到目标端。 
   空间的考虑
        在一对多的数据复制场景中,由于多库的数据需要复制到一个库中,对数据复制所需的空间必须提前预留. 可以采取如下措施:

     1) 在源端采取数据过滤来降低目标端的数据空间需求
     2) 在路由判断中,只复制满足条件的数据到目标端,既提前处理数据,只同步,复制满足条件的记录到目标端.

     单表到单表的同步

    同步支持情况如下 :

NO	场景	分类	GoldenGate是否支持	实现方式
1	表结构相同		支持	mapping
2	表结构不同	字段类型不同	支持	GoldenGate转换函数
3		字段数量不同	支持	mapping
4		字段名称不同	支持	mapping
5	过滤(通过本表字段)		支持	GoldenGate(filter)
6	过滤(通过本地其它表关联查询)		支持	DP on source
7	源或目标端有聚合操作,如, group,average, sum等		不支持

    单表到多表的同步
       可以拆分为”单表到单表”的同步来实现. 主要分如下的同步场景:

NO	场景	分类	GoldenGate是否支持	实现方式
1	单表分解为多表（不同的字段到不同的表）		支持	mapping
2	单表复制到多表（相同的字段到不同的表）		支持	mapping
3	单表记录分发到不同的表中（根据条件不同，选择不同的记录到不同的表中）		支持	Mapping+where

 

     支持的场景
     Oracle GoldenGate的数据同步是基于表级的,对于多表的到单表的同步需求,实质是也是通过单表到单表的同步来实现。
        1)多表到单表的数据同步需要满足: 源端的每一个表与目标端的表的记录之间有关联关系。或通过主键,唯一键,或其它关键字段。
        2) 在采用不同主键关联的父,子,孙表关系中, 关联的级别不能超过3级. 
     单表中的数据过滤(Filter)，

          请参见如下场景：

场景 A表join B表 数据同步到目标端C表	业务同步需求	GoldenGate同步 (only need column or filter cloumn)	filter	other
A-b(join)->c	同步A，B	A ，B	na
A jion b and filter on a ->c	A，B	A,B	Ex on source
A jion b and filter on b ->c (1:1)(c include only a)	A	A	Dp on source	Mv on source+ex on source
A jion b and filter on b ->c (n:1)	A	A	Dp on source	Mv on source+ex on source
A jion b and filter on b ->c (1:n)	A	A,B	Dp on target	Mv on source+ex on source

   多表到多表的同步
      可以拆分为N个多表到单表的同步来解决 

   数据过滤(Filter)规范
      Join 的表不能超过3张。 
      Filter 的where 只处理=，>=,<=,in,not in,like 并且不能带任何函数，in 和not in中只能是list.
      Filter 和 join的字段必须同时被一个索引所包含。  

架构设计规范
   总体架构设计示例图
    1)只有对于本机的复制（不经过中间网络）引入直接传输模式，即不使用Data Pump。例如，在一台主机上有多个业务系统，需要在各业务系统之间进行复制，可以按照直接传输模式（即没有Data Pump的模式）设计链路；
    2)只要复制需要通过中间网络，则需引入Data Pump，通过Data Pump进行数据传输。
    3)
    4)目标端的datapump为可选,其目的是为了均衡数据同步负载.
    5)如果有blob/clob同步的需求,必须使用专用的Extract进程, 使之与其它进程区分开.
    6)为了使数据同步对源数据库的影响降到最低, 在源端的Extract进程,不能超过3个.
  进程合并 
      1)进程根据需要同步的数据库分工来分工, 一个数据库对应相应的extract、replicat, datapump
      2)对于同一个数据库的同步,不允许多个replicat进程
      在经过细分以后的结构图中，有时候一台主机上会出现多个同类进程，可以参照以下原则尝试合并：
       进程合并一般只针对于一对多的Extract合并；
       只能对于同一台主机上的同一个GoldenGate安装目录下进程进行合并；
       合并从主Extract进程开始，其原则为当向多个目标复制的数据集相同或大部分数据范围相同重叠时进行合并，否则无需合并；
       主Extract合并以后，本地队列自动随之合并；
       Data Pump根据源端的本地队列和目标主机的组合进行配置，一般无需合并；
       Replicat进程根据传输到目标主机的队列个数进行配置，一般无需合并。
      例如，上例中的一对二复制合并后为：
      说明：如果是对于多对一复制，Replicat进程是无法进行合并的，因为多个源过来的队列只能是多个队列，而一个Replicat只能处理一个队列。例如，下列二对一复制例子中的Replicat无法合并：
 进程拆分
     为了保证源端数据提交的顺序,在目标端严格顺序执行, 原则上replicat进程不拆分
     在进程合并后，可能因为性能问题需要进行进程拆分。拆分的原则如下
        对于主Extract的拆分，一般可以遵循：
        如果源数据库日志产生量超过20G/小时，则考虑进行主Extract拆分；
        可以最繁忙阶段每小时日志量除以20G估算主Extract拆分的个数；
        主Extract拆分依次以Schema、Table、单个表的Range作为拆分依据，使各拆分出来的Extract负载均衡。
        主Extract拆分要考虑到事务一致性，即尽量将同一业务设计的表放在同一个Extract进程内。
        Data Pump无需拆分
        Replicat拆分。由于OGG的Replicat是单线程投递数据，一般均需进行拆分，以实现多线程并行工作，加快投递速度。其拆分原则为：
        以投递性能作为拆分依据。一般拆分数量需经过几次测试实验而得，建议按照表分配到多个进程，保证各进程间负载均衡；
        对于某些特大表，可以对单个表按照Range拆分为多个replicat进行处理；
        在拆分时，需要注意外键引用关系，保证有外键关系表在同一个进程。如无法保证，则建议将目标的外键约束临时禁用，以后如需接管业务提前启用即可。
     例如，上例中的一对二复制拆分后可能的结构图为：
  多进程与数据一致性规范
    Oracle GoldenGate进程之间是没有通讯机制的，为了保证数据的一致性，在设计结构的时候通过以下途径进行保证：
    首先，将同一交易涉及的表划分在同一个进程组内，由于进程内部是完全保证交易一致性的，不会出现数据不一致情况；
    其次，采用单一Extract和多个Replicat的模式。由于Extract性能较高，一般客户源系统每小时不超过20G日志，可以在源端配置一个主Extract进程抽取所有的表，在抽取到队列时即可以保证交易一致性；而在目标端，通常为了性能考虑需要配置多个Replicat进程，它们之间可能存在临时的不同步，但是由于源端主Extract是单个的，所以目标端队列文件中的数据实际是保持了数据一致性的，在配置了足够Replicat后能够跟上队列产生的速度，此时各Replicat进程之间的时间差异一般会在1秒以内，只存在短暂差异。而在接管业务时，可以等待若干秒时间等待所有Replicat把队列中数据应用完毕，此时目标库已经可以保证交易数据的完整性和一致性了。
    由此可见，客户无需担心因为GoldenGate多进程并行处理带来交易数据不一致的问题。
  架构优化设计方案
     1．尽量采用并行结构。将事务量分配到多个并发执行的GoldenGate进程组上，以加快数据复制速度。一个进程组包含一个Extract(抽取)进程，一个或多个Datapump(传输)进程，一个或多个Replicat(加载)进程，以及专供它们使用的Trail(队列)文件。如图1所示。
     2．预先估计各个表上的事务量，尽量将事务平均分配到不同的进程组上。
     3．具有关联关系的表（例如，主外键），应被分配到同一个进程组，以保证事务完整性。
     4．对一个Extract进程，应该使用多个Datapump进程，以充分利用网络的并发能力，快速将源端Trail文件传输到目标端。如果Datapump进程没有做过滤和转换，则将其调整到PASSTHRU模式下运行。
     5．对于目标端的每个Trail文件，建议使用一到两个Replicat进程并行加载。具有关联关系的表应该放到同一个Replicat进程，以保证事务完整性。
     6．单个GoldenGate实例上，并发进程数目不得超过200个。如果系统内存较少（少于8G），则这个数目应该更小。
     7．如果表具有以下特征，应该使用单独的进程组进行复制：
         包含LOB字段
         包含不能记录到事务日志的字段
         事务特别繁忙
         事务处理时间特别长
         字段数目很多而且无法找到主键
     8．如果某表上的事务过于繁忙，则应对该表进行行分割。使用@RANGE函数，将一张表的不同行近似均匀的分配到多个GoldenGate进程组。可以从Extract端进行分割，也可以从Replicat端进行。建议从Extract端进行分割。如图2示。
   9．过滤和转换应该尽量使用Datapump或Replicat，而不是Extract。如果源端不能受到太大的影响，则应该在目标端或单独的服务器上进行过滤和转换。
  10．应将Trail文件分散到不同的磁盘上，以充分利用每个磁盘的IO性能。对GoldenGate而言，RAID 0+1比RAID 5更加适合GoldenGate进程的IO需求。

 

CC文件命名规范

• ExtractParam:EXP+ 源库 HOST+ 源库 SID+ 目标 HOST+ 目标库 SID.prm        如 :EXP_g1bh8040_ELIS_g2bh8070_LDSH0.prm

• DataPumpParam: DPP+S+ 源库 HOST+ 源库 SID+ 目标库 HOST+ 目标库 SID.prm /DPP+R+ 源库 HOST+ 源库 SID+ 目标库 HOST+ 目标库 SID.prm

     如:DPP_S_g2bh8070_ELIS_g1sz8040_LDSH0.prm / DPP_R_g1sz8040_LDSH0_g2bh8070_ELIS.prm

• ReplicatParam: REP+ 源库 HOST+ 源库 SID+ 目标库 HOST+ 目标库 SID.prm 如 :REP_g1sz8040_LDSH0_g2bh8070_ELIS.prm

• Definition: DEF+ 源库 HOST+ 源库 SID.def           如 :DEF_g2bh8070_ELIS.def

• Shell: 数据库 HOST+ 数据库用户 .sh         

• 如 :g2bh8070_oggepcis.sh