ogg灾备运维指标预防方案.docxVIP

ogg复制进程预防延迟解决方案 sql语句的数量，从而达到优化 sql语句的数量，从而达到优化 grouptra nspos 500 三、并行处理与进程拆分： 拆分粒度： （1） 可以通过schema进行区分，每个复制链路负责一个或多个 schema； （schema下的表太多，不适合这种拆分） （2） 也可以根据表进行分割，每个进程负责不同表的集合； （可以进行这种拆分） （3） 对于同一个表也可以通过 Ran ge拆分为几个进程同时处理。例如：（可以进行这种拆分，尤其对于这个表上存在大交易，大量事务） Replicat 1 : MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (1,2)); Replicat 2 : MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (2, 2)); 进程拆分的注意事项 （1） 各进程间没有同步机制，应尽量确保同一交易事务涉及表在一个进程。 （2） 单个extract进程可处理日志一般为30-50G/小时，单个replicat 进程一般只能处理1G队列/小时，可采用一个extract对多个replicat 的模式。 （3） 由于extract在catch up （追赶）模式需要读取归档日志，速度慢且耗费资源高，建议 extract 一旦出现较大延迟则立即进行拆分 保证抽取一致性 由于OGC的Extract性能较高，可以使用尽量少的 Extract完成抽取（1个），多个抽取进程之间以业务或 Schema进行区分，单个Extract抽 取出来的队列中可以保证交易的一致性和先后顺序。 尽量保证投递一致性 （1） 如单个Replicat无法满足一个队列投递数据要求，可以根据表进行分割，每个进程负责不同表的集合，尽量保证同一业务涉及表放在一个 Replicat中，可以保证一致性；（需临时禁止表间的外键链接保证 Replicat可进行拆分） （2） 对于同一个表也可以通过 Range拆分为几个进程同时处理，Replicat拆分可能临时造成各进程间不同步，但是多个 Replicat性能会得到很大 提高，可以保证数据复制始终是实时的 当源端出现灾难后，由于 Extract可以保证源端抽取时数据的一致性，而目标端多 Replicat读取的是同一个队列，当它们应用队列数据完毕 后是可以达到数据一致的 而在Goldengate的Pump进程把这些日志传送到容灾端以后，由于容灾端的机器配置一般不如生产端的高。再加上与 Replicat相比Extract 本身的入库速度就比较慢。这会导致日志在容灾端大量的堆积， Replicat出现延时。这就需要对 GoldenGate的Replicat进程进行拆分，来增加入 库的速度。 拆分也有一定限度，不可以无止境的去拆分。因为每个Replicat都会占用系统的内存资源，而且会占用CPI资源。所以如果拆分太多的Replicat， 把系统的内存消耗完了以后，反而会导致入库的速度理慢。在拆分的时候要根据实际情况进行有效的拆分。 四、示例： (1) STEP 1:停止要拆分的进程 stop repya ⑵STEP 2:查看要拆分进程的SEQN和RBA号 info repya 或 send repya,status ⑶STEP 3 :为要新的进程编辑参数文件，这里叫做 repyb edit params repyb ⑷STEP 4 :添加repyb进程组，并为其添加trail文件 add replicat repyb , exttrail ./dirdat/yb checkpo in ttable ⑸STEP 5 :修改repyb的指针和repya相同 alter repyb , extse qno 1 extrba 117945 ⑹STEP 6 :再次确认repya和repyb的指针已经修改到一致状态。 info repya info repyb ⑺STEP : 一定要记住要把repya中拆分repyb中的表排除掉，否则会有重复数据 edit params repya tableexclude scott.dept (8) STEP :启动 repya 和 repyb。 start rep* 到这里goldengate 就把比较慢的进程拆分到了不同的两个进程里面，可以加快入库速度。 五、主健和唯一索引影响复制性能 OGG复制性能和要复制的表是否存在主键和唯一索引有很大关系，所以从应用系统开发商对表结构的规范也会更为有效