DBA_JOBS中BROKEN='Y'表示作业因连续失败（默认1次）被Oracle自动停用，NEXT_DATE设为4000-01-01作为失效标记；须先查LAST_ERR定位真实错误（如ORA-01031权限不足、ORA-12008刷新链断裂等），再执行DBMS_JOB.BROKEN(job=>x,broken=>FALSE,next_date=>SYSDATE)重置并COMMIT，最后手动RUN验证；12c+推荐迁移到DBMS_SCHEDULER以获得可控重试与完整错误追踪。
DBA_JOBS里BROKEN=Y，基本就是连续失败触发了自动保护
oracle对dbms_job作业设了硬性失败阈值：只要连续执行失败（默认1次），就会把broken字段设为true，同时把next_date改成4000-01-01——这不是时间写错了，是oracle的“失效标记”。你看到broken = 'y'，第一反应不该是修job本身，而是查它为什么反复失败。
常见诱因包括：
-
ORA-01031（权限不足）：JOB进程拿不到ALTER ANY MATERIALIZED VIEW或基表/MLOG$_*的SELECT权限，角色权限不生效 -
ORA-12008（刷新链断裂）：刷新组里MV依赖顺序错乱，比如B依赖A但A还没刷完，B就读到了中间态 -
ORA-12012（调度表达式错误）：NEXT写成字符串如'SYSDATE + 1'，Oracle当字面量解析直接报错 - 日志表损坏或缺失：
staleness = 'UNUSABLE'时FAST刷新必然失败，JOB重试后挂起
查LAST_ERR比看FAILURES次数更管用
FAILURES只告诉你失败了多少次，LAST_ERR才暴露真正卡在哪。直接查：
SELECT job, what, last_date, next_date, broken, failures, last_err FROM dba_jobs WHERE what LIKE '%dbms_mview.refresh%' AND job = <your_job_id>;</your_job_id>
如果LAST_ERR是ORA-00942，说明缺表或权限；如果是ORA-01031，立刻去补ALTER ANY MATERIALIZED VIEW；若为空但failures > 0，大概率是ORA-12008这类内部错误，得结合DBA_MVIEWS.staleness和DBA_REFRESH_CHILDREN.broken交叉验证。
DBMS_JOB.BROKEN(false)必须配next_date，否则下次照样跳过
只执行DBMS_JOB.BROKEN(job => 123, broken => FALSE)不够。Oracle会保留旧的NEXT_DATE（可能是4000-01-01），下次调度仍视其为无效时间而跳过。必须显式指定有效时间：
BEGIN DBMS_JOB.BROKEN(job => 123, broken => FALSE, next_date => SYSDATE); END;
注意点：
- 别用
TO_DATE函数——它依赖NLS_DATE_FORMAT，DBA一调参数，所有JOB批量失效 - 手动触发一次
DBMS_JOB.RUN(123)，能快速确认底层问题是否已解决 - 改完必须
COMMIT，否则BROKEN状态不生效
12c+环境下，BROKEN问题本质是DBMS_JOB已淘汰
DBMS_JOB在12c里没被删，但已被DBMS_SCHEDULER取代。它不记录详细错误日志，failures只计数不存堆栈，排查全靠猜；而DBMS_SCHEDULER自带MAX_FAILURES、RESTART_ON_FAILURE、STOP_ON_WINDOW_CLOSE等可控参数，还能绑定资源组限CPU。生产环境还在用DBMS_JOB，等于主动放弃可观测性——BROKEN不是偶然，是机制缺陷的必然结果。
