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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2128539/，如需转载，请注明出处，否则将追究法律责任。