oracle 12c物化视图无法在只读备库实时刷新——因ora-16000硬限制，所有刷新操作均被拒绝；可行方案是主库刷新+备库查询重写，依赖enable query rewrite与real-time apply。
为什么备库上执行 DBMS_MVIEW.REFRESH 会报 ORA-16000
物理备库（即使启用了 Active Data Guard）处于 OPEN READ ONLY 状态，所有物化视图刷新操作（REFRESH FAST 或 REFRESH COMPLETE）本质都是 DML/DDL 写入，直接违反只读约束。Oracle 不会尝试解析或重放逻辑，而是在调用瞬间抛出 ORA-16000: database open for read-only access。
常见误判点：
- 以为
REFRESH ON COMMIT能同步到备库 —— 实际只在主库生效，日志回放的是物理块变更，不包含 PL/SQL 逻辑 - 以为建了
MLOG$_xxx日志就能在备库维护 —— 日志表本身是写对象，只读状态下禁止创建或更新 - 查
V$MVLOG发现日志存在就认为可用 —— 备库上该视图返回空或无效数据，不可信
主库刷新 + 备库查询重写的实操要点
可行路径是让主库负责刷新、备库负责高效查询，核心依赖 ENABLE QUERY REWRITE 和 REAL-TIME APPLY。
必须满足的条件：
- 主库创建物化视图时显式加上
ENABLE QUERY REWRITE，且确保QUERY_REWRITE_ENABLED=TRUE（系统级或会话级） - 主库基表 DML 提交后，立刻触发
REFRESH ON COMMIT或调度DBMS_MVIEW.REFRESH('MV', 'F')，保证主库侧数据最新 - 备库开启
REAL-TIME APPLY（即USING CURRENT LOGFILE），检查V$DATAGUARD_STATS中apply lag≤ 5 秒 - 应用连接备库时，SQL 的
WHERE条件字段必须出现在物化视图SELECT列表中，且不能含阻断函数（如SYSDATE、ROWNUM）
权限和定义陷阱：
- 用户需显式授予
QUERY REWRITE权限（SELECT ANY TABLE不替代） - 物化视图定义里漏掉常用过滤字段（如基表按
time_id分区，但 MV 没选time_id），WHERE time_id > ...就无法重写 - 备库未显式启用重写：
ALTER SESSION SET query_rewrite_enabled = TRUE
ON QUERY COMPUTATION 在 12.2+ 的真实表现
这是唯一能绕过“刷新延迟”的机制，但它不是“实时刷新”，而是“查询时动态合并变更”——本质是优化器把 stale MV + 物化视图日志（MAS$ 表）做 UNION ALL 和 HASH JOIN OUTER，再算出最新结果。
关键约束：
- 必须搭配
WITH ROWID和INCLUDING NEW VALUES的物化视图日志，否则日志无法捕获 UPDATE/DELETE 后的新镜像 - 不兼容
ON COMMIT刷新，也不能和传统FAST刷新混用 - 每次查询都触发基表扫描 + 日志比对，若基表无索引或变更量大，性能反而更差
-
STALENESS显示NEED_COMPILE是正常现象，不代表失效；只要QUERY_REWRITE_ENABLED=TRUE且成本足够低，CBO 仍会重写
最容易被忽略的细节：分区表与查询重写
物化视图完全不感知基表是否分区，它只认自己 SELECT 里的逻辑。哪怕基表按 time_id 分了 100 个分区，MV 也只存一张扁平表。
重写失败的典型原因：
- 物化视图定义中没包含实际查询常用的维度字段（如
region、product_category），导致 WHERE 条件无法匹配 - 基表有分区裁剪，但 MV 的 GROUP BY 或 SELECT 没对齐分区键，重写器直接放弃
- 物化视图日志建在默认表空间（如
SYSTEM），大数据量下 I/O 瓶颈拖慢日志消费，间接影响REAL-TIME APPLY延迟
分区表日志必须单独指定高性能表空间：CREATE MATERIALIZED VIEW LOG ON sales TABLESPACE mvlog_tbs，且日志字段要覆盖所有 JOIN、GROUP BY、WHERE 中出现的列。
