必须先在源库建物化视图日志，再在目标库建DBLINK和物化视图；顺序错误导致REFRESH FAST失败，常见原因为日志未建在源库、源表缺主键/唯一约束、DBLINK权限不足。
必须先在源库建物化视图日志，再在目标库建dblink和物化视图，顺序错一步，refresh fast 就会直接失败。
为什么 REFRESH FAST 总报 ORA-12004 或 ORA-12052？
这是最常踩的坑：错误提示往往指向“无法快速刷新”，但真实原因几乎全是前置条件缺失。关键点有三个：
- 物化视图日志没在源库（远程库）上创建，而是在本地库执行了
CREATE MATERIALIZED VIEW LOG ON ...—— 这完全无效； - 源表没有主键或唯一约束，却用了
WITH PRIMARY KEY； - DBLINK 权限不足，比如源库用户没被授予对
MLOG$_TABLENAME视图的SELECT权限（日志表默认只对 owner 可见）。
验证是否就绪：在源库查 SELECT * FROM user_mview_logs WHERE master = 'YOUR_TABLE';，必须有结果；在目标库用 DBLINK 能查到该日志表（如 SELECT * FROM MLOG$_YOUR_TABLE@dblink_name WHERE ROWNUM=1;）才算通。
CREATE MATERIALIZED VIEW 语句里哪些参数不能省？
跨库场景下，这几个子句不是可选，而是强制依赖关系：
-
BUILD IMMEDIATE：不加的话，物化视图创建后是空的，容易误判成功； -
REFRESH FAST ON DEMAND：跨库不支持ON COMMIT（Oracle 11g 限制），必须显式写ON DEMAND； -
WITH PRIMARY KEY或WITH ROWID：决定增量识别方式；若源表有主键，优先用WITH PRIMARY KEY，否则必须确保查询中包含ROWID并加WITH ROWID； -
ENABLE QUERY REWRITE：非必需，但加了才能让优化器自动把原查询重写为走物化视图，否则只是个“手动缓存表”。
典型语句示例（目标库执行）：
CREATE MATERIALIZED VIEW mv_emp_sync<br> BUILD IMMEDIATE<br> REFRESH FAST ON DEMAND<br> WITH PRIMARY KEY<br> ENABLE QUERY REWRITE<br>AS<br> SELECT empno, ename, deptno FROM emp@hr_dblink;
手动刷新时 dbms_mview.refresh 的参数陷阱
调用 DBMS_MVIEW.REFRESH 看似简单，但两个参数的大小写、格式和上下文极易出错：
- 第一个参数是物化视图名，必须全大写（除非建的时候用双引号定义了小写名）；
- 第二个参数用单字母简写时，
'F'和'C'必须大写；用全称时，'FAST'和'COMPLETE'也区分大小写； - 不要传入 DBLINK 名或远程表名——它只操作本地物化视图对象；
- 并发刷新多张表时，用逗号拼接名（如
'MV_A,MV_B,MV_C'），但注意总长度不能超 32 字节（Oracle 11g 限制）。
安全写法：
EXEC DBMS_MVIEW.REFRESH('MV_EMP_SYNC', 'F');比
exec dbms_mview.refresh('mv_emp_sync','f') 更可靠。
增量刷新失败后，别急着重启，先查三处日志
REFRESH FAST 卡住或报错后，直接重跑 COMPLETE 是常见但低效的做法。真正该看的是：
-
user_mview_analysis视图：查SELECT * FROM user_mview_analysis WHERE mview_name = 'MV_EMP_SYNC';，重点关注capable_flag和refresh_method是否为FAST； -
dba_mview_logs（源库）：确认日志是否启用INCLUDING NEW VALUES，否则新增行不会被捕获； -
DBA_JOBS或DBA_SCHEDULER_JOBS（如果用了定时任务）：检查 job 是否因权限或连接超时失败，而不是单纯看物化视图本身。
最容易被忽略的是：物化视图日志一旦创建，后续对源表的 DDL（如加列）可能使日志失效，但 Oracle 不主动报错，只在下次 FAST 刷新时静默降级为 COMPLETE——得靠 user_mview_analysis 主动发现。
