物理备库无法执行DBMS_MVIEW.REFRESH，因只读模式禁止DML/DDL；唯一合法方式是转为快照备库（需闪回启用），刷新后再切回物理备库。
备库默认只读，dbms_mview.refresh 会直接报 ora-16000
Oracle 12c 物化视图在物理备库（Physical Standby）上无法执行手动 COMPLETE 刷新，根本原因是：物理备库的数据库打开模式是 READ ONLY 或 READ ONLY WITH APPLY，而 DBMS_MVIEW.REFRESH(method => 'C') 内部会执行 TRUNCATE + INSERT /*+ APPEND */ 操作——这属于 DML/DDL 写入行为，违反只读约束。Oracle 在检查时立即抛出 ORA-16000: database open for read-only access，不进入实际刷新逻辑。
为什么 ALTER DATABASE OPEN READ WRITE 不行
物理备库不能随意切为读写模式，否则会彻底脱离 Data Guard 同步链路：
- 执行
ALTER DATABASE OPEN READ WRITE会终止 Redo Apply，且无法自动恢复；后续必须人工重建备库或执行 failover，不再是“备库” - 即使临时切换，
DBMS_MVIEW.REFRESH还需依赖基表、日志表、物化视图自身所在的表空间处于ONLINE状态——而备库中部分表空间可能被置为OFFLINE（如归档专用表空间） -
DBMS_MVIEW.REFRESH调用过程中会尝试更新OBJ$和MVIEWS$元数据，这些系统基表在只读模式下不可修改
备库上真能刷物化视图的唯一合法路径
只有在 **快照备库（Snapshot Standby）** 模式下，才允许执行 DBMS_MVIEW.REFRESH。因为 Snapshot Standby 是物理备库的临时可写形态：
- 先在主库执行
ALTER DATABASE CONVERT TO SNAPSHOT STANDBY（需已启用闪回数据库） - 重启备库后，它以
READ WRITE模式启动，此时DBMS_MVIEW.REFRESH('MV_NAME', 'C')可正常执行 - 刷新完成后，必须再执行
ALTER DATABASE CONVERT TO PHYSICAL STANDBY并重启，才能重新接入 Redo Apply - 注意：
CONVERT TO SNAPSHOT STANDBY会丢弃自上次转换以来未应用的归档日志，需确保主库归档已传全，否则切换后会丢失数据
别试“绕过只读”的野路子
有人试图用 ALTER SYSTEM SET READ_ONLY_OPEN_DELAYED=TRUE 或修改 v$database.open_mode 伪字段来欺骗刷新过程——这些操作无效，且可能损坏控制文件或触发实例崩溃。Oracle 的只读校验发生在函数入口级，不是靠参数开关控制的。
真正需要在备库用物化视图的场景，应提前设计为：在主库完成刷新后，通过 DB Link 查询主库 MV（需主库开放权限），或改用备库本地的只读等价物（如普通视图 + 定期导出导入）。强行在物理备库刷 MV，本质上违背了 Data Guard 的架构定位。
