今天同事讓我幫一個忙，說現在有兩個環境中的一張表資料不一致，已經造成了一些資料問題，他們已經排查了一圈，最後發現是一張表的資料問題導致，希望我來幫忙協助一下。

他們提供了詳細的源庫，目標庫的連結，看起來一起都明確了，那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_DATE
-------------------- ------------------------------ -------------------- ------- ----------
TESTAGENT            TESTTYPE                       MATERIALIZED VIEW    VALID   2013-12-24

這個問題和開發同事進行了溝通，解釋的也還算順利，看來他們又得說服自己來處理這種資料的不一致了。

通過這個案例可以看到，很多時候我們都得說服自己，可能有些問題最開始方向就是錯的，我們得嚴密的進行論證，要不就會錯上加錯。