資料同步中的誤導

今天同事讓我幫一個忙，說現在有兩個環境中的一張表資料不一致，已經造成了一些資料問題，他們已經排查了一圈，最後發現是一張表的資料問題導致，希望我來幫忙協助一下。
他們提供了詳細的源庫，目標庫的連結，看起來一起都明確了，那DBA需要做的事情就很明朗了。
本來以為資料訪問結構圖是下面的形式，即兩個不同的資料庫環境，彼此都有對應的屬主使用者和連線使用者，彼此之間獨立。那麼同步資料就需要考慮是否是全量，增量等等。

但是檢視了一圈，發現結構比自己想象要複雜一些。類似下面的形式
左邊是源庫，源庫中存在屬主使用者和連線使用者，分別對應表和同義詞，
右邊是目標庫，裡面存在屬主使用者和連線使用者，分別對應的是物化檢視和同義詞，這一點有一些奇怪的是，目標庫中是透過db link來訪問源庫的同義詞建立了物化檢視。

如果這樣來看，兩邊的資料應該很可能是一致的，如果不一致，那就應該是物化檢視沒有重新整理同步導致的。
帶著疑問檢視了源庫的資料條數
> select count(*)from testtype;
  COUNT(*)
----------
       709
在目標庫中檢視，發現確實不匹配。
> select count(*)from testtype;
  COUNT(*)
----------
       731
那麼如此來看確實是資料不同步導致的，那麼我們就來重新整理一下物化檢視來修復這個問題。
SQL> exec dbms_mview.refresh('TESTTYPE','C');
按照開發同事提供的思路，這是一個很自然的過程。
但是檢視重新整理後的資料情況，還是731條，這個時候感覺應該是哪裡出現了問題，唯一的可能就是物化檢視了。
結果一看物化檢視的ddl語句。
原來是類似這樣的結構
select xxxxx from testtype where xxxx
union all
select xxxxx  from testtype where xxxxx;
這樣來看，確實很可能兩邊的資料不一致了。那麼這樣一來，問題看起來就可能不是單純的資料不一致的問題造成的了。這種資料的變化應該就是希望根據業務來定製出來的，所以在目標庫做了集合運算。那麼怎麼來說服開發同事呢，有一個辦法，就是從資料字典裡抓出來這個物化檢視的定義，一看都是好幾年前的了，如果出問題早就出了。也不在最近才有這種事情。
OWNER                OBJECT_NAME                    OBJECT_TYPE          STATUS  CREATE_DAT
-------------------- ------------------------------ -------------------- ------- ----------
TESTAGENT            TESTTYPE                       MATERIALIZED VIEW    VALID   2013-12-24
這個問題和開發同事進行了溝通，解釋的也還算順利，看來他們又得說服自己來處理這種資料的不一致了。
透過這個案例可以看到，很多時候我們都得說服自己，可能有些問題最開始方向就是錯的，我們得嚴密的進行論證，要不就會錯上加錯。