Oracle只读物化视图不支持本地修改，仅能从主库拉取数据并用于只读查询；可更新物化视图需加入物化视图组并启用高级复制，否则本地修改将在刷新时丢失。
Oracle只读物化视图不支持本地修改
只读物化视图就是一张“快照表”，创建时不带 FOR UPDATE，也不加入物化视图组。它只从主库拉取数据，本地任何 INSERT/UPDATE/DELETE 都会直接报错，比如 ORA-12081: update not allowed on materialized view "HR"."DEPARTMENTS"。
常见错误现象：在只读物化视图上执行 DML，哪怕只是 UPDATE departments SET name = 'x' WHERE id = 1，立刻失败；试图加 FOR UPDATE 子句查它，也无效（Oracle 忽略该子句，不报错但不起锁作用）。
- 刷新必须由主库驱动，本地只能调用
DBMS_MVIEW.REFRESH或依赖ON COMMIT/ON DEMAND策略 - 适合场景：报表查询、BI 只读分析、异地只读副本
- 优势是简单稳定，无一致性风险；劣势是完全无法响应本地写入需求
可更新物化视图必须属于物化视图组且启用高级复制
可更新物化视图不是语法开关，而是一整套复制架构：它必须显式声明 FOR UPDATE，且通过 DBMS_REPCAT.CREATE_MVIEW_REPGROUP 和 CREATE_MVIEW_REPOBJECT 加入物化视图组，并启用高级复制（Advanced Replication）。
它的核心能力是双向同步：你在本地改了物化视图，下一次刷新时，这些变更会被打包发回主库（需主库接受并应用）。但这不是实时的，仍存在延迟和冲突可能。
- 不满足条件（如没建组、没启高级复制），
FOR UPDATE就只是个无效修饰符，视图仍是只读 - 刷新方式只能是
FAST（基于物化视图日志），COMPLETE刷新会丢弃本地修改 - Oracle 12c 及以后已标记高级复制为“deprecated”，官方推荐用 GoldenGate 或 Oracle Data Guard 替代
别混淆“可写物化视图”这个陷阱概念
所谓“可写物化视图”，是指创建时写了 FOR UPDATE 但**没加入物化视图组**——它看起来能本地写入（INSERT 成功），但下次 REFRESH 一跑，所有本地改动就彻底消失。这不是设计特性，而是误用导致的数据丢失漏洞。
典型错误操作：CREATE MATERIALIZED VIEW mv_emp FOR UPDATE AS SELECT * FROM emp@remote;，没走 DBMS_REPCAT 流程，就以为能本地编辑。
- 这种视图在
DBA_MVIEWS中显示UPDATABLE = 'YES'，但只是元数据误导，实际不可靠 - Oracle 文档明确指出：未加入组的
FOR UPDATE物化视图，“local changes will be lost on refresh” - 监控时注意查
DBA_REGISTERED_SNAPSHOTS，只有这里登记过的才真正参与复制
刷新机制与锁行为的根本差异
只读和可更新物化视图在刷新时都**不影响查询可用性**，因为 Oracle 默认使用一致性读（MVCC），旧快照一直可查。但它们对锁和事务的参与完全不同：
- 只读物化视图刷新期间：基表上不会加特殊锁；物化视图本身不参与任何事务隔离，
SELECT ... FOR UPDATE在其上无效 - 可更新物化视图刷新时：会尝试将本地变更合并到主库，若主库对应行已被其他事务锁定，就会触发冲突检测（如
ORA-12048: error encountered while refreshing materialized view） - 两者都不支持在物化视图上建行级锁（
SELECT ... FOR UPDATE对物化视图无意义），真要加锁，必须回到主表操作
最易被忽略的一点：可更新物化视图的“更新”不是原子操作，它依赖日志捕获、网络传输、主库应用三个环节，任一失败都会导致数据不一致，且排查链路远比只读模式复杂得多。
