Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

86

积分

0

好友

4

主题
1#
发表于 2012-6-13 11:44:00 | 查看: 6774| 回复: 2
在看论坛里《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是如何处理的?
2#
发表于 2012-6-13 14:07:32
对于无主键表的 ogg 复制

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


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

回复 只看该作者 道具 举报

3#
发表于 2012-6-13 14:24:20
就是说,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),是吗?

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 22:31 , Processed in 0.047420 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569