GoldenGate複製的幾個簡單測試

今天測試了一下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的同步的時候還是能夠保證這個準確性，而且在一些更為負載的場景中，可以輕鬆做到欄位對映之類的細粒度選擇複製，實屬不易。