dbms_scheduler.create_job必须显式指定enabled=>TRUE才生效，否则STATE为DISABLED且NEXT_RUN_DATE为NULL；repeat_interval对大小写、空格等敏感，需严格按日历表达式格式书写；带参存储过程须封装wrapper或改用PLSQL_BLOCK类型。
dbms_scheduler.create_job 必须显式启用才生效
很多人写完 dbms_scheduler.create_job 就以为任务会自动跑起来，结果发现 NEXT_RUN_DATE 一直是 NULL，STATE 是 DISABLED。根本原因是 enabled => TRUE 这个参数不是默认值，漏写就等于禁用。
常见错误写法：dbms_scheduler.create_job(job_name=>'myjob', job_type=>'STORED_PROCEDURE', job_action=>'my_proc') —— 缺少 enabled=>TRUE，job 创建后处于休眠状态。
正确做法必须明确指定：
-
enabled => TRUE（推荐，一步到位） - 或创建后手动启用：
dbms_scheduler.enable('myjob')
另外注意：如果 job_name 已存在，create_job 会直接报错 ORA-27477: job "MYJOB" already exists，需先 drop_job 或用异常处理兜底。
repeat_interval 的语法容错率极低，别手写
repeat_interval 看似是字符串，实则是 Oracle 内部解析的“日历表达式”，空格、大小写、分号、时区都敏感。比如 'FREQ=DAILY; INTERVAL=1' 合法，但 'freq=daily;interval=1'（小写）或 'FREQ=DAILY;INTERVAL=1 '（末尾空格）都会导致 ORA-27450: invalid calendar string。
建议用标准格式，且优先使用 Oracle 内置函数生成时间点，避免硬编码：
- 每月 5 号凌晨 2 点：
'FREQ=MONTHLY; BYMONTHDAY=5; BYHOUR=2; BYMINUTE=0' - 每周一至五早 8 点：
'FREQ=WEEKLY; BYDAY=MON,TUE,WED,THU,FRI; BYHOUR=8; BYMINUTE=0' - 每 15 分钟一次（更可靠）：
'FREQ=MINUTELY; INTERVAL=15'，而非'sysdate+15/1440'（那是dbms_job的写法，不适用于 scheduler）
调试时可用 dbms_scheduler.evaluate_calendar_string 验证表达式是否合法：
DECLARE
next_date TIMESTAMP;
next_sec NUMBER;
BEGIN
DBMS_SCHEDULER.EVALUATE_CALENDAR_STRING(
'FREQ=DAILY; BYHOUR=2; BYMINUTE=0',
SYSTIMESTAMP,
SYSTIMESTAMP,
next_date,
next_sec
);
DBMS_OUTPUT.PUT_LINE('Next run: ' || next_date);
END;
存储过程带参数？不能直接传，得用命名程序
dbms_scheduler.create_job 的 job_action 参数只接受「无参」对象名（如 'my_proc'），若你的存储过程需要传参（比如 proc_high_settle_rep_month(p_startdate IN VARCHAR2, p_enddate IN VARCHAR2)），直接写会报 ORA-27469: job_action must be a valid PL/SQL block or stored procedure name。
解决方案只有两个：
-
封装成无参 wrapper：新建一个不带参数的存储过程，在里面调用原过程并填好参数（如用
add_months(sysdate,-1)算上月范围） -
改用 PLSQL_BLOCK 类型：把整个调用逻辑写成匿名块，例如：
job_action => 'BEGIN proc_high_settle_rep_month(to_char(add_months(sysdate,-1),''YYYYMM'')||''01'', to_char(last_day(add_months(sysdate,-1)), ''YYYYMMDD'')); END;'—— 注意单引号要双写，且字符串长度不能超 4000 字节
别试图在 job_action 里拼接变量或用绑定变量，scheduler 不支持运行时参数绑定。
权限和环境变量常被忽略，尤其在跨用户或 RAC 场景下
即使语句语法全对，job 也可能静默失败。典型原因包括：
- 执行 job 的用户（即
create_job的当前用户）没有对目标存储过程的EXECUTE权限 —— 即使是自己写的，也要显式GRANT EXECUTE ON my_proc TO my_user - 在 RAC 环境中，job 默认可能只在某个节点调度；若依赖本地文件、外部命令或特定监听器，需确认
job_class是否设为跨实例类（如'DEFAULT_JOB_CLASS'通常安全） - 脚本类 job（如
EXECUTABLE类型）依赖操作系统 PATH 和环境变量，而 scheduler 启动的 shell 不读取~/.bashrc，必须在脚本开头显式. /etc/profile或设置完整路径
查失败原因最直接的方式是查日志：SELECT log_date, status, error# FROM USER_SCHEDULER_JOB_LOG WHERE job_name = 'MYJOB' ORDER BY log_date DESC。status 为 FAILED 时，error# 字段就是 Oracle 错误码（如 6550 表示 PL/SQL 编译错误）。
