GG在同步无主键表如何保证在初始化期间的更新

Wizard

在看论坛里《GG运维宝典》中讲到GG的初始化数据从源端到目标段时，需要开启一对extract-replicat进程，捕获在initial loading期间源端的表所发生的改变（update、insert，delete），待初始化数据同步完成后，再使用trail文件将初始化期间的dml应用到目标端表。
这让我觉得有些像oracle的实例回复中的使用redo log。 但是我不太明白的是：
假设：1、源端要进行同步的表没有主键、且没有可供用来标示记录唯一性的个别列，则GG应该采用全列组合，来表示一条唯一记录
         2、该没有主键的表在初始化期间，数据因业务操作，发生变化

结论/猜想： GG是如何把数据变化准备应用到已发生改变的纪录上去的？还是GG对这种情况无法保证准确更新，会产生一条discard的记录？如果在repliat中配置了INSERTMISSINGUPDATES参数，会不会多处一条记录？

图示说明：
       源表                                                                                      在同步期间值改变为
        cost           profit         GST        costomer                                                                       cost           profit         GST        costomer
         12.9          1.8             2.0          333                              --------------------------〉               12.9          2.0            1.8          666
       --------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     目标表  初始化之后
        cost           profit         GST        costomer
          12.9          2.0            1.8          666

     目标表 应用初始化期间的trail
          cost           profit         GST        costomer                       ---------------------〉  期望的结果， 该条记录在应用完trail后，依然正确
         12.9          2.0            1.8          666

猜想：
       目标表 应用初始化期间的trail
          cost           profit         GST        costomer                       ---------------------〉  因为找不到对应的记录，更新被丢弃， 这条记录变成死记录
         12.9          1.8           2.0          333

          cost           profit         GST        costomer                       ---------------------〉 使用了INSERTMISSINGUPDATES后，多出了一条新记录，但老的记录变成了死记录，同时给基于该表的统计分析引入错误
         12.9          1.8           2.0          333
        12.9          2.0            1.8          666

请教刘大，该情形，GG是如何处理的？

Wizard

就是说，GG有自己的机制，在初始化完成后redo 初始化期间的变化时，可以找到已经变化的记录，并保持其正确的结果，不会找不到
所以GG结果应该是：
目标表 应用初始化期间的trail
          cost           profit         GST        costomer                       ---------------------〉  期望的结果， 该条记录在应用完trail后，依然正确
         12.9          2.0            1.8          666
？
不知道我的理解对不对？
就是说，在应用trail时 trail里记录的是： 对key为（12.9-1.8-2.0-333）的行执行 set 1.8=2.0， 2.0=1.8， 333=666的操作，但是此时目标端数据库已经变成了（12.9-2.0-1.8-666），所以实际上GG无法找到（12.9-1.8-2.0-333）这条记录了。这是我的困惑的地方

刘大的意思是GG有它的机制可以保证该行与源表一致（12.9-2.0-1.8-666），是吗？

Maclean Liu(刘相兵

对于无主键表的 ogg 复制

Oracle 9i对于大于32列的
表可能会增加附加日志失败，必须将所有列划分为若干组自行添加（注意：使用该方法生成的附加日志使用info trandata无法识别）
Alter table <table> add supplemental log group <group> (column,..) always;
10g以上没有32列限制问题


GoldenGate可以正常复制无主键表，以所有列作为基准代替主键
强烈建议排除掉无主键表或者增加主键（或唯一索引）
一般为临时表或者历史表
导致附加日志增量较大，可能影响生产系统性能
目标端replicat投递效率非常低且无法进行优化
容易出现数据不一致且不易修复
无法使用HANDLECOLLISIONS（该参数依赖于表的主键进行逻辑判断，无主键表使用该参数会导致重复记录出现）