GoldenGate复制的三个简单测试场景（r10笔记第83天）

今天测试了一下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的同步的时候还是能够保证这个准确性，而且在一些更为负载的场景中，可以轻松做到字段映射之类的细粒度选择复制，实属不易。