今天同事让我帮一个忙，说现在有两个环境中的一张表数据不一致，已经造成了一些数据问题，他们已经排查了一圈，最后发现是一张表的数据问题导致，希望我来帮忙协助一下。
他们提供了详细的源库，目标库的链接，看起来一起都明确了，那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
这个问题和开发同事进行了沟通，解释的也还算顺利，看来他们又得说服自己来处理这种数据的不一致了。
通过这个案例可以看到，很多时候我们都得说服自己，可能有些问题最开始方向就是错的，我们得严密的进行论证，要不就会错上加错。