Oracle定时任务不执行，90%是job_queue_processes为0或NEXT_DATE停滞；先查参数值并设为10～100，再确认BROKEN状态、权限、AUTHID设置及时区一致性。
Oracle定时任务不执行，90%的情况不是代码写错了，而是环境或状态没调对。先查 job_queue_processes 是否为 0，再看 NEXT_DATE 是否停滞不动——这两项不对，后面所有逻辑都白搭。
job_queue_processes 为 0 是最常见原因
这个参数控制数据库能启动多少个 JOB 后台进程。值为 0 时，所有 DBMS_JOB 任务都会“静默挂起”，DBA_JOBS 里看着一切正常，但 NEXT_DATE 死活不更新。
- 用
SHOW PARAMETER job_queue_processes查当前值；如果是 0，立刻执行ALTER SYSTEM SET job_queue_processes = 10（建议设为 10～100，别设 1000，老版本 Oracle 可能触发内部限制） - 该参数修改后立即生效，无需重启实例
- RAC 环境下需在所有节点确认该参数值，
GV$PARAMETER比V$PARAMETER更可靠 - 注意：Oracle 10g 及之后版本默认启用
DBMS_SCHEDULER，但job_queue_processes仍影响DBMS_JOB，且某些旧应用强依赖后者
DBMS_JOB 的 NEXT_DATE 长期不变说明什么
NEXT_DATE 停在某个时间点不再推进，基本可断定任务已“卡住”。这不是延迟，是调度器根本没尝试执行。
- 手动运行一次：
EXEC DBMS_JOB.RUN(<job_number>)</job_number>—— 如果成功，说明存储过程本身没问题，问题出在调度链路上 - 检查
BROKEN字段是否为Y：即使你没主动 break，异常未捕获、权限缺失或对象失效都可能导致 Oracle 自动置为 broken - 若
BROKEN = Y，先修复根源（比如重新编译存储过程、补权限），再用DBMS_JOB.BROKEN(<job_number>, FALSE)</job_number>解除 broken 状态 -
FAILURES字段 > 0 时，必须查DBA_JOBS_RUNNING或后台 alert 日志，ORA- 错误码才是真实线索
存储过程权限和 AUTHID 设置容易被忽略
手动 EXEC 成功 ≠ JOB 能跑。JOB 以创建者身份、在独立会话中运行，上下文完全不同。
- 确保存储过程中所有引用的对象（表、视图、序列等）都已向 JOB 所属用户显式授权，不能只靠角色继承
- 避免使用
AUTHID CURRENT_USER，除非你明确需要动态解析调用者 Schema；多数场景下AUTHID DEFINER（默认）更稳妥 - 如果存储过程里用了
DBMS_OUTPUT.PUT_LINE，记得在 JOB 中加DBMS_OUTPUT.ENABLE—— 否则日志全丢，错误无声无息 - 事务控制要显式：
COMMIT或ROLLBACK必须写全，否则 JOB 会因未提交事务而阻塞后续调度
DBMS_SCHEDULER 任务失败常因大小写或时区错乱
如果你用的是 DBMS_SCHEDULER.CREATE_JOB，失败往往不报具体 ORA 错误，而是直接跳过执行。
- 存储过程名大小写敏感：如果建过程时用了双引号（如
"my_proc"），job_action参数必须完全匹配大小写；否则 Oracle 默认转大写去查，找不到就静默失败 - 检查
DBA_SCHEDULER_GLOBAL_ATTRIBUTE中的DEFAULT_TIMEZONE，与数据库时区（DBTIMEZONE）不一致会导致start_date和repeat_interval解析错乱 -
REPEAT_INTERVAL用FREQ=DAILY; BYHOUR=2这类字符串时，务必确认时区缩写（如Asia/Shanghai）是否被正确识别，否则可能“每天执行”变成“每 24 小时执行一次”，偏差越来越大 - 不要在
job_action中直接传参；带参存储过程必须包装成命名程序（DBMS_SCHEDULER.CREATE_PROGRAM），否则报ORA-27469
真正难排查的从来不是语法，而是那些看不见的状态：参数值、时区、权限边界、broken 标记。每次改完配置，盯住 NEXT_DATE 和 LAST_DATE 是否开始滚动，比看日志更快定位问题根子。
