能创建跨库物化视图，但必须用DB_LINK显式引用远程表且仅支持COMPLETE刷新；FAST刷新因无法同步远程MLOG$日志而不可用，启用会报ORA-12015。
能创建，但必须用 DB_LINK 显式引用远程表，且只能用 COMPLETE 刷新——FAST 在跨库场景下基本不可用，强行启用会报 ORA-12015。
建物化视图前必须确认的三件事
漏掉任意一项，CREATE MATERIALIZED VIEW 会直接失败或后续刷新异常：
-
DB_LINK必须由当前用户拥有（不能是PUBLIC），且状态正常：运行SELECT * FROM USER_DB_LINKS WHERE DB_LINK = 'MY_LINK'确认存在且USERNAME、HOST可达 - 本地用户需被授予
CREATE MATERIALIZED VIEW权限（不是ANY）；若用ATOMIC_REFRESH => FALSE，还需DROP ANY TABLE - 远程表的
SELECT权限必须显式授予本地用户：在远程库执行GRANT SELECT ON schema.table TO local_user，仅靠DB_LINK用户权限不生效
CREATE MATERIALIZED VIEW 语句的合法写法
错误写法：AS SELECT * FROM remote_user.table@my_link —— 表名带 @ 是允许的，但必须出现在 FROM 子句中，且不能在子查询或表达式里裸写；更关键的是，Oracle 不允许在物化视图定义中直接写远程对象别名（如 remote_user.table@my_link t），会触发 ORA-00942。
正确结构（以 ON DEMAND + COMPLETE 为例）：
CREATE MATERIALIZED VIEW mv_sales_cache BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND AS SELECT /*+ NO_MERGE */ id, name, amount FROM sales@my_link;
注意点：
-
BUILD IMMEDIATE推荐加上，否则视图创建后为空，需手动首次刷新 -
NO_MERGE提示是防 Oracle 优化器把远程查询改写成本地 join，导致权限或网络解析失败 - 字段列表必须明确，避免用
*—— 远程表加列后本地 MV 不失效，但查询结果错位
刷新时最容易踩的坑：权限和事务设置
调用 DBMS_MVIEW.REFRESH('mv_sales_cache', 'C') 报错，大概率不是语法问题，而是环境配置缺失：
- 报
ORA-02069：说明数据库参数global_names为TRUE，但DB_LINK名与远程库全局名不一致；临时解法是ALTER SESSION SET global_names = FALSE（不推荐长期关闭） - 报
ORA-02041（未初始化分布式事务）：刷新用户缺少对DB_LINK的执行权限，需在本地库执行GRANT EXECUTE ON my_link TO local_user - 用
ATOMIC_REFRESH => FALSE时，底层会DROP+RECREATE表，要求本地用户对远程表有SELECT ANY TABLE或对应对象权限，否则刷新中途卡死
为什么不要指望 FAST 刷新跨库生效
所谓 FAST 依赖远程库上的 MLOG$ 日志表实时捕获变更，但 Oracle 不支持通过 DB_LINK 同步日志内容。即使你在远程库手动建了 MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY，本地物化视图仍无法读取其变更记录。
尝试 REFRESH FAST ON DEMAND 会直接报 ORA-12015，因为 Oracle 检测到查询涉及远程对象，自动禁用增量逻辑。生产环境若真需要近实时同步，应考虑：DBMS_SCHEDULER 配合 COMPLETE 刷新（间隔拉长至 5–15 分钟），或改用 GoldenGate / Data Guard 等专用复制工具。
最危险的静默故障点：远程表结构变更后，物化视图不会自动失效，SELECT 仍返回旧结构数据——必须定期核对 DESCRIBE mv_sales_cache 和 SELECT * FROM sales@my_link WHERE ROWNUM = 1 字段顺序与类型。
