OGG_relicat进程丢数据 handlecolisions个人想法

  最近接手一套OGG，开发人员抱怨有很多时间点的数据丢失，希望我们排查原因并解决问题。

首先着手了解ogg的功能：确认只开启dml，未开启ddl操作；然手找丢失数据的类型，主要从：

1、stats replicat 进程名字，发现insert、update、delete等dml操作都有操作记录，排除了该OGG不能同步update的猜测；

2、minus对比数据，发现部分表行数一直，但表内容有差别；部分表行数就缺；部分表行数和表内容完全一直。（个人表示萌萌的,毫无规律！）

3、查询丢数据或数据不一致的的时间点，发现时间点比较一致。也就是说都是某一时刻会集中有些insert或是update未能同步；

-----考虑中----

会不会是这样！（灵感突显后的兴奋）

跟源端dba确认，在丢丟数的时间点是否重新初始化过部分表，而且初始化的方式是基于scn的方式。得到的回复是肯定的。 那就明白了。

基于expdp+scn的方式初始化ogg，看似是绝对不会丢数据，但是忽略了数据库长事务问题。倘若做初始化的时刻，因为各种原因源端数据库依然进行着各种事务，并且部分事务是长事务。本来ogg是从在线日志或是归档日志中抽取sql，如果是数据库的长事务ogg处理起来就力不从心了。

找到原因就开始找解决办法了：

两个思路：1、重配，注意scn时刻事务问题，或是直接rman初始化；2，使用handlecolisions参数，配合基于时间点恢复启动replicat进程；

我选择了第二个,原因：

1、这套ogg仅支持dml操作；

2、同步的表均有主键或唯一索引；

3、这样搞不行，还可以再重配；

4、handlecolisions参数性质，很有意思。

使用HANDLECOLLISIONS的几个场景：

1、target丢失delete记录(missing delete)，忽略该问题并不记录到discardfile
2、target丢失update记录(missing update)
            更新的键值是主键=》 update转换成INSERT ，默认情况下插入记录不完整
            更新的键值是非主键=》 忽略该问题并不记录到discardfile
3、重复插入已存在的主键值到target表中，这将被replicat转换为UPDATE现有主键值的行的其他非主键列情景

理解一下上面的话：

丢失的delete不操作，后面跟的操作可能是insert，重复了就转为update，没有问题；如果后面就不做操作了，到时目标端多些数据，删除就好；

丢失的是update非主键，就不做操作，没问题；如果是主键，但一般主键都是标记唯一的sequence，问题也不太大；

丢失的如果是insert，不重复就插入，没问题；如果主键重复就update为新的内容，也没问题。

综上就是对主键update会有问题，可能造成数据的不完整，每个表都看看，并咨询一下开发，貌似不会对主键update。

好，就这么搞了。

再replicat进程配置文件中加入handlecolisions参数，并alter replicat replicat_name,begin 时间。

我把时间提前到该scn（scn去查当时的时间是可查的）的前10分钟，同步发现还是少那个时间点之前的数据。这正实了我的猜想，就是因为长事务问题，导致少数据！好吧，我把时间点移到当天晚上凌晨3点，再同步，发现问题解决了。ok！万事大吉！

---------------------当然上面的一些想法，可能在专家面前是站不住脚的，毕竟学疏才浅，望海涵，指正！

                                                                                                                                          如想沟通技术等问题，请联系   王杰   15314117200

                                                                                                                                                                                           夏家祥 QQ592379255