今天和开发的同事讨论一个问题，他们说source 1的环境中存在一个表，现在希望目标环境target 1和target 2中都需要用到这部分的数据。 对于这个问题看似处理也比较常规。就是直接在两个目标端创建db link相关的同义词。 对于这个需求和开发的同事进行了初步的讨论，首先涉及两个表，这个两个表中的数据都在几百几千，所以说数据量很小。如果存在相关的查询，其实性能应该还能接受。 不过从我的角度来看，我还是希望在目标端是两个local的表而不是通过db link的方式每次都去从源端取得数据。 所以在数据量之外，了解到这两个表在目标端是只读权限，那么看起来物化视图是一个不错的方案。 接着问题来了，在源端的表是否会经常做dml操作，得到的反馈是会，但是不是很频繁，一旦发生dml操作就需要在目标端及时体现。 从这个需求的情况来看，在目标端使用db link创建的物化视图，通过物化视图的自动刷新可以实现这个需求。 也就是下面的实现方式。 一旦源端出现了任何的dml操作，都可以在commit之后及时同步刷新，这个方案其实从应用的角度来看还是蛮符合的。 所以和他们进行了简单的确认，明确了需求环境，就准备开始做了。 首先在目标端多个用户中都需要引用这个表的数据，所以考虑使用public db link，而且实际上我也不知道应用端的用户密码。如果要操作还需要再做一轮加密解密。 然后考虑在目标端的owner用户创建对应的物化视图，在连接用户创建同义词指向物化视图。比如目标端1是这么考虑的。 看起来一切都在可控之中，然后简单配置后，在源端创建了物化视图日志。 create materialized view log on mtest.test with rowid; 然后就开始在目标端创建物化视图，但是报了下面的错误。 SQL> create materialized view test build immediate refresh fast on commit as select * from mtest.test@mtest_link; create materialized view test build immediate refresh fast on commit as select * from mtest.test@mtest_link                                                                                                    * ERROR at line 1: ORA-12014: table 'TEST' does not contain a primary key constraint 看起来是主键的问题，因为在源端的表还没有主键，所以感觉这种自动刷新的瓶颈是不是在这儿了，和开发的同事沟通了一下，他们也很配合，可以加主键，不过是复合列，听起来也还不错，然后简单评估之后，他们就提供了对应的索引规则。但是部署之后还是有问题。 create materialized view test refresh on commit as select * from mtest.test@mtest_link * ERROR at line 1: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view 对于这个问题也感觉有些茫然，到底是语法问题还是其它的权限问题呢。在各种尝试，refresh complete on commit也不行。 最后在MOS上看了看，原来又是一个无情的bug. Materialized View Creation With ON COMMIT Fails With ORA-12054 When Using DBLINK (Doc ID 301627.1) 对于这类问题，通过db link方式的形式使用on commit的自动刷新还是存在一些问题。 那没辙了，目前我美好的设想都泡汤了，还得用看起来不太美的db link形式的同义词了。继续琢磨琢磨，看看还有什么更好的方式，而且要轻量。

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