Oracle DBMS_JOB定时任务未正常执行时间字段未更新问题

这种情况我在日常运维中碰到过好多次，你的定时任务配置语法看起来没问题，但时间字段始终没更新，核心原因基本是任务根本没被调度执行，咱们一步步来排查：

1. 先确认Job队列进程是否启用 #

Oracle的DBMS_JOB依赖于job_queue_processes参数，这个参数决定了数据库同时能运行多少个job调度进程。如果它的值是0，所有job都会处于停滞状态，完全不会被执行。

执行这条SQL检查参数值：

SELECT value FROM v$parameter WHERE name = 'job_queue_processes';

如果返回0，赶紧把它改成大于0的数值（比如10，可根据你的业务需求调整）：

ALTER SYSTEM SET job_queue_processes = 10 SCOPE=BOTH;

说明：SCOPE=BOTH会同时修改内存和参数文件，重启数据库后依然生效；如果只是临时测试，可以用SCOPE=MEMORY仅修改当前会话的内存配置。

2. 检查Job的状态和失败次数 #

任务没执行，大概率是第一次运行就失败了，Oracle会因为连续失败暂停对该job的调度。执行这条SQL查看你的job详情：

SELECT job, status, failures, last_date, next_date, what 
FROM dba_jobs 
WHERE job = [你的Job编号]; -- 替换成你创建任务时输出的Job Number

• 如果status显示为FAILED，failures字段会记录失败次数，这时候你需要手动执行存储过程，排查它本身的问题：

  EXEC PROCEDURE_CATCH;
  

  看看有没有报错——比如存储过程依赖的表/视图不存在、权限不足、逻辑错误导致的异常，这些都会让job执行失败，进而停止后续调度。

3. 验证时间配置是否合理 #

你设置的interval是SYSDATE + 1/24/12，也就是每5分钟执行一次，这个语法是完全正确的，但如果job从未成功执行过，last_date、next_date这些字段肯定不会更新。所以先解决前面两个问题，再观察时间字段的变化。

4. 查看Alert日志找线索 #

如果上面的排查还没找到原因，去数据库的Alert日志里搜这个job的编号，Oracle会把job执行的报错细节记录在这里，能帮你定位更隐蔽的问题（比如系统资源不足、锁冲突、存储过程调用的外部服务不可用等）。

额外提示：考虑迁移到DBMS_SCHEDULER #

DBMS_JOB是比较老旧的调度工具，Oracle 10g及以后官方推荐使用DBMS_SCHEDULER，它功能更强大，监控和排查也更直观。不过先把当前的DBMS_JOB问题解决了，再考虑迁移也不迟。

内容的提问来源于stack exchange，提问作者civesuas_sine