RESTRICTED 模式下无法刷新物化视图是 Oracle 硬性限制：受限会话全局禁用 job 执行，导致基于 DBA_JOBS/DBMS_SCHEDULER 的自动及多数手动刷新静默失败；ON COMMIT 刷新亦失效，因内核拒绝调用非基础 DML 的 PL/SQL 逻辑。
RESTRICTED 模式下无法刷新物化视图——这不是配置问题，而是 Oracle 的硬性限制：只要数据库处于 RESTRICTED SESSION 状态，所有基于 job 的自动刷新和大部分手动刷新调用都会静默失败或直接被拒绝。
为什么 RESTRICTED SESSION 会阻断刷新？
Oracle 的物化视图刷新（尤其是 ON DEMAND 模式）严重依赖后台作业机制（DBA_JOBS 或 DBMS_SCHEDULER）。而 RESTRICTED SESSION 会全局禁用 job 执行，无论 job_queue_processes 是否 > 0。
- 查询
SELECT LOG_USER, WHAT FROM DBA_JOBS WHERE WHAT LIKE '%REFRESH%'会返回记录，但状态始终为BROKEN = 'Y'或FAILURES > 0 - 手动执行
DBMS_MVIEW.REFRESH可能报ORA-12008或ORA-01031: insufficient privileges，实际是权限校验在 restricted 下被强化 -
ON COMMIT刷新同样失效：事务提交时内核尝试触发刷新路径，但受限模式下拒绝调用任何非基础 DML 相关的 PL/SQL 扩展逻辑
验证当前是否处于 RESTRICTED 模式
别猜，直接查：
SELECT LOGINS FROM V$INSTANCE;
返回值为 RESTRICTED 即确认受限。也可查：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'restrict_all_tables';
若为 TRUE，说明连直连基表都受限，更别说刷新物化视图。
绕过限制的唯一可行方式：临时退出 RESTRICTED
没有“在 restricted 下强制刷新”的合法路径。必须由具有 ALTER SYSTEM 权限的用户执行：
-
ALTER SYSTEM DISABLE RESTRICTED SESSION;—— 立即解除限制（无需重启） - 刷新完成后再恢复：
ALTER SYSTEM ENABLE RESTRICTED SESSION; - 注意：此操作影响全局，需协调运维窗口；若使用 RAC，需确认所有实例均已退出 restricted
切勿尝试用 DBMS_SCHEDULER 创建 job 并指定 connect_identifier 绕过——scheduler job 同样受 RESTRICTED 抑制，且无法跨模式切换会话上下文。
如果真不能退出 RESTRICTED，只能降级处理
极少数合规场景（如审计锁定期）禁止退出 restricted，此时唯一选择是：
- 改用
COMPLETE刷新 +atomic_refresh => FALSE，在受限会话中直接执行（不走 job）： BEGIN DBMS_MVIEW.REFRESH('OWNER.MV_NAME', method => 'C', atomic_refresh => FALSE); END;- 但前提是：当前用户对基表有
SELECT权限、对物化视图有UPDATE权限，且 undo 表空间充足（因非原子刷新仍需回滚段支持） - 该方式不依赖 job，但会短暂暴露不一致数据，且大 MV 易触发
ORA-01555
真正棘手的不是语法或参数，而是受限模式本身切断了 Oracle 刷新链路的底层调度能力——这点容易被忽略，直到发现 NEXT 时间到了、job 看起来在跑、日志却空空如也。
