GoldenGate复制的几个简单测试

  1. 云栖社区>
  2. 博客>
  3. 正文

GoldenGate复制的几个简单测试

jeanron100 2016-11-15 23:12:32 浏览328
展开阅读全文

今天测试了一下GoldenGate的复制,发现还是有不少的细节之处需要测试,保证可控,而下面做了几个测试也加深了我对OGG的理解。
默认是不支持DDL的,而线上业务的DDL也是完全可控的,在升级前几天可以冻结DDL,所以在线业务中还是充分利用DML的数据变化即可,不过这些影响还是需要测试到的,做到心中有数。
源端在Solaris下,数据库为10gR2,所以适用的OGG版本只是11.2的版本了。目标端为Linux X86,数据库为11gR2,也是使用同样版本的OGG软件。
同步的过程可以参考之前的一篇文章,我们来做3个测试。
测试1

我们插入一些数据,然后看看DDL的情况下,数据的同步情况。
源端插入一些数据。

n1@TESTDB> insert into test_tab select level,level||'obj' from dual connect by level<500000;
499999 rows created.
n1@TESTDB> commit;
Commit complete.

目标端查看,很快就同步过来了。

SQL>select count(*)from test_tab;
  COUNT(*)
----------
    499999

然后源端做一个truncate操作

n1@TESTDB> truncate table test_tab;
Table truncated.

接着源端插入一条数据,这样源端只存在1条数据

n1@TESTDB> insert into test_tab values('aaa','TAB');
1 row created.
n1@TESTDB> commit;
Commit complete.

目标端:       

SQL> select count(*)from test_tab;
  COUNT(*)
----------
    500000 由此可见,对于DDL类的操作,OGG默认是处理不了,新的数据变更还是能够正常应用。


测试2:我们测试一些delete的场景,看看OGG的同步情况,数据基于测试场景1
源端:

n1@TESTDB> delete from test_tab;
1 row deleted.
n1@TESTDB> commit;
Commit complete.

目标端:

SQL>select count(*)from test_tab;
  COUNT(*)
----------
    500000
SQL> /
  COUNT(*)
----------
    499999

可见这个场景中,竟然主库是一个delete的操作,没有过滤条件和delete全表等价,但是在应用的时候,还是做了过滤的条件应用,而非语句直接应用。

测试3,我们加入一些略微复杂的过滤条件,看看OGG的应用情况。
源端:

n1@TESTDB> delete from test_tab where rownum<500000;
0 rows deleted.
n1@TESTDB> commit;
Commit complete.

目标端,数据没有变化

  COUNT(*)
----------
    499999

通过上面的例子可以看出,主库做了条件删除,rownum相对是一个较模糊的概念,在OGG的同步的时候还是能够保证这个准确性,而且在一些更为负载的场景中,可以轻松做到字段映射之类的细粒度选择复制,实属不易。

网友评论

登录后评论
0/500
评论
jeanron100
+ 关注