根本原因是后台进程jnnn权限隔离：需显式授予alter any materialized view、基表及mlog$_*日志表select权限，且job_queue_processes>0、无restricted session，next/start with必须为date表达式而非字符串。
根本原因不是“job没跑起来”，而是后台进程 jnnn 拿不到权限、读不到表、或压根没被调度——手动刷新走你当前会话，自动 job 走 oracle 内部独立会话，二者权限模型完全隔离。
查 job 是否已 broken 或 next_date 异常
自动 Job 看似“不执行”，实则可能已被 Oracle 主动停用。运行：
SELECT job, broken, failures, last_date, next_date, what FROM user_jobs WHERE what LIKE '%MV_%';
若 broken = 'Y' 且 failures > 0，说明它已因错误被挂起；next_date 显示为 4000-01-01 是失效标记，不是时间写错了。
- 不要只看
what字段是否含物化视图名，要确认该 job 对应的物化视图是否真在user_mviews中存在 -
last_date为空或远早于当前时间，基本可判定调度链断裂 - 如果
what里调用的是DBMS_MVIEW.REFRESH，但没带atomic_refresh => FALSE等关键参数，也可能导致隐式失败
验证 job_queue_processes 和 RESTRICTED SESSION
这是最常被忽略的底层开关。即使 job 定义完好，这两个条件任一不满足，所有 job 都静默不触发：
- 执行
SELECT value FROM v$parameter WHERE name = 'job_queue_processes';—— 若返回0，任何 job 都不会启动 - 执行
SELECT logins FROM v$instance;—— 若返回RESTRICTED，必须立即执行ALTER SYSTEM DISABLE RESTRICTED SESSION; - Oracle 12c+ 默认
job_queue_processes=1000，但 RAC 或升级后可能被重置为 0，不能假设它“应该”是开启的
权限必须显式授予，角色权限无效
手动执行时你有 CONNECT、RESOURCE 或自定义 role，但 jnnn 进程不继承 role，只认直接 grant 的权限：
- 必须执行
GRANT ALTER ANY MATERIALIZED VIEW TO your_user;—— 这是DBMS_MVIEW.REFRESH自动模式下元数据更新所必需的，缺了就报ORA-01031 - 若物化视图基表在其他 schema（如 MV 在
SCHEMA_A，基表在SCHEMA_B），需对每个基表单独GRANT SELECT ON SCHEMA_B.TABLE_X TO your_user; - 快刷依赖日志表，检查
MLOG$_TABLENAME是否存在、大小写是否匹配、是否在正确 schema 下，并确保有SELECT权限
NEXT 和 START WITH 必须是表达式，不能是字符串
写成 NEXT 'SYSDATE + 1' 或 START WITH TO_DATE('2026-04-29', 'YYYY-MM-DD') 会导致 ORA-12012：Oracle 把它当字面量解析，而非可执行代码。
- 正确写法只能是函数调用：
NEXT TRUNC(SYSDATE) + 1 + 8/24（每天早 8 点）、START WITH SYSDATE - 避免
TO_DATE—— 它依赖会话级NLS_DATE_FORMAT，DBA 一旦改全局设置，所有含TO_DATE的 job 就批量失效 - 验证方式：
SELECT next_date FROM user_mviews WHERE mview_name = 'YOUR_MV_NAME';返回值必须是有效日期类型，不能是NULL或非法字符串
真正卡住的地方往往不在物化视图定义本身，而在后台进程能访问什么、能执行什么、以及调度器有没有被系统级开关拦住。每一步都要用实际 SQL 去验证，而不是“我以为有权限”或“参数看起来没问题”。
