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

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