对于这个问题看似处理也比较常规。就是直接在两个目标端创建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形式的同义词了。继续琢磨琢磨，看看还有什么更好的方式，而且要轻量。