物化视图无“离线”状态，所谓离线实为停刷新：需保留对象、禁用调度任务（不删job）、ON COMMIT模式须先切为ON DEMAND，确保日志表完好，严禁DROP或TRUNCATE，前端查询不受影响。
物化视图离线时前端查询报 ORA-12083: must use DROP MATERIALIZED VIEW to drop "SCHEMA"."MV_NAME"
这不是真报错，是误操作信号：你执行了 drop materialized view，但实际只想停刷新。物化视图一旦被删，底层表就没了，前端查 select * from mv_name 必然失败。
正确做法是保留对象、只停调度。Oracle 不提供 “offline” 状态开关，所谓“离线”只能靠停刷新 + 锁定刷新入口来模拟。
- 用
DBMS_MVIEW.REFRESH手动触发后，立刻禁用关联的DBMS_SCHEDULERjob（别删 job，否则元数据丢失） - 若用
ON COMMIT刷新，必须先改刷新模式：ALTER MATERIALIZED VIEW mv_name REFRESH ON DEMAND，否则提交事务仍会偷偷刷新 - 检查是否被物化视图日志依赖：
SELECT master, log_table FROM user_mview_logs WHERE log_owner = 'SCHEMA'，停刷新前别动日志表，否则后续恢复可能失败
如何安全暂停刷新又不让前端查不到数据
核心原则：数据还在，只是不更新。只要物化视图基表（mv_name）没被删、没被 truncate、没被 ALTER ... REBUILD，前端 SELECT 就完全不受影响。
真正要防的是别人误操作或自动任务干扰：
- 运行
EXEC DBMS_MVIEW.REFRESH('MV_NAME', 'C')完成最后一次全量同步，再停调度 - 查当前刷新方式：
SELECT refresh_method, build_mode FROM user_mviews WHERE mview_name = 'MV_NAME'；若为FAST且依赖日志，确保日志表未被清理（user_mview_logs中对应项存在） - 禁止直接
TRUNCATE TABLE mv_name—— 这会清空数据，前端立刻查不到；要用DELETE FROM mv_name+COMMIT才保留段结构（但一般没必要删数据）
ALTER MATERIALIZED VIEW ... DISABLE QUERY REWRITE 有用吗
没用。这个语句只影响基于该物化视图的查询重写（query rewrite），比如优化器把查大表的 SQL 自动转成查 MV。它不控制 MV 本身是否可查，也不影响刷新行为。
立即学习“前端免费学习笔记（深入）”；
前端直查 SELECT * FROM mv_name 走的是表扫描，跟 query rewrite 开关无关。停刷新和保证可查是两件事，别混在一起操作。
- 如果你的应用依赖 query rewrite（比如查
fact_sales却命中了mv_sales_summary），那停刷新后 rewrite 仍生效，但返回的是旧数据 —— 这属于业务预期问题，不是技术故障 - 确认 rewrite 是否启用：
SELECT rewriting_enabled FROM user_mviews WHERE mview_name = 'MV_NAME'；值为YES才受DISABLE QUERY REWRITE影响
恢复刷新时最常漏掉的一步
改回刷新模式后，忘记重新启用 scheduler job 或补上 ON COMMIT 触发器。
例如你之前用 ON DEMAND 停了刷新，恢复时只执行了 ALTER MATERIALIZED VIEW mv_name REFRESH FAST ON COMMIT，但没重建触发器，那 COMMIT 后依然不会刷。
- 查触发器是否存在：
SELECT trigger_name FROM user_triggers WHERE triggering_event LIKE '%UPDATE OR INSERT OR DELETE%' AND table_name = 'MV_NAME' - 如果用 scheduler job，运行
DBMS_SCHEDULER.ENABLE('JOB_NAME')，别只改状态字段 - 首次恢复后建议手动跑一次
DBMS_MVIEW.REFRESH，确认日志能读、快刷能过，再交还给自动机制
物化视图没有“挂起”状态，所有“离线”操作本质都是人工干预刷新链路。最容易忽略的是日志表权限和 job 的 enable 状态 —— 看似停好了，一恢复就卡在第一次刷新失败。
