dbms_scheduler创建后state是null

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.2.5.7
【问题描述】使用dbms_scheduler创建了job（JOB_INSERT_RZ）后，state是null，又创建一个job（JOB_INSERT_RZ1），这两个job只是start_date不同，JOB_INSERT_RZ1的state正常
【复现路径】问题出现前后相关操作
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => ‘JOB_INSERT_RZ’,
job_type => ‘STORED_PROCEDURE’,
job_action => ‘INSERT_RZ’,
start_date => TO_TIMESTAMP(‘2026-08-05 12:00:00’,‘YYYY-MM-DD HH24:MI:SS’),
repeat_interval => ‘FREQ=DAILY; INTERVAL=1’,
enabled => TRUE);
END;
/

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => ‘JOB_INSERT_RZ1’,
job_type => ‘STORED_PROCEDURE’,
job_action => ‘INSERT_RZ’,
start_date => SYSTIMESTAMP,
repeat_interval => ‘FREQ=DAILY; INTERVAL=1’,
enabled => TRUE);
END;
/

SELECT JOB_NAME, ENABLED, NEXT_RUN_DATE, STATE, LAST_START_DATE FROM DBA_SCHEDULER_JOBS ;
±------------------------------------±--------±------------------------------------±----------±------------------------------------+
| JOB_NAME | ENABLED | NEXT_RUN_DATE | STATE | LAST_START_DATE |
±------------------------------------±--------±------------------------------------±----------±------------------------------------+
| ASYNC_GATHER_STATS_JOB_PROC | 1 | 04-AUG-26 11.33.13.801801 PM +08:00 | SCHEDULED | 04-AUG-26 11.18.13.803638 PM +08:00 |
| FRIDAY_WINDOW | 1 | 07-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 31-JUL-26 10.00.00.001812 PM +08:00 |
| JOB_DEL_LOG | 1 | 05-AUG-26 11.14.14.485667 PM +08:00 | SCHEDULED | 04-AUG-26 11.14.24.328422 PM +08:00 |
| JOB_INSERT_YDRZ | 1 | 05-AUG-26 12.00.00.000000 PM +08:00 | NULL | NULL |
| JOB_INSERT_YDRZ1 | 1 | 05-AUG-26 11.20.02.654572 PM +08:00 | SCHEDULED | NULL |
| MONDAY_WINDOW | 1 | 10-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 03-AUG-26 10.00.00.002478 PM +08:00 |
| OPT_STATS_HISTORY_MANAGER | 1 | 05-AUG-26 02.00.00.000000 AM +08:00 | SCHEDULED | 04-AUG-26 02.00.00.001868 AM +08:00 |
| SATURDAY_WINDOW | 1 | 08-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 01-AUG-26 10.00.00.001913 PM +08:00 |
| SCHEDULED_TRIGGER_DUMP_DATA_DICT | 1 | 05-AUG-26 01.04.00.000000 AM +08:00 | SCHEDULED | 04-AUG-26 11.04.00.001145 PM +08:00 |
| SCHEDULED_TRIGGER_PARTITION_BALANCE | 1 | 05-AUG-26 12.00.00.000000 AM +08:00 | SCHEDULED | 04-AUG-26 12.00.00.001077 AM +08:00 |
| SPM_STATS_MANAGER | 1 | 05-AUG-26 01.00.00.000000 AM +08:00 | SCHEDULED | 04-AUG-26 01.00.00.002105 AM +08:00 |
| SUNDAY_WINDOW | 1 | 09-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 02-AUG-26 10.00.00.001993 PM +08:00 |
| THURSDAY_WINDOW | 1 | 06-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 30-JUL-26 10.00.00.002726 PM +08:00 |
| TUESDAY_WINDOW | 1 | 11-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 04-AUG-26 10.00.00.001678 PM +08:00 |
| WEDNESDAY_WINDOW | 1 | 05-AUG-26 10.00.00.000000 PM +08:00 | SCHEDULED | 29-JUL-26 10.00.00.001059 PM +08:00 |
±------------------------------------±--------±------------------------------------±----------±------------------------------------+
15 rows in set (0.016 sec)

请问是什么原因呢？

8 个赞
#3

@论坛小助手

2 个赞
#4

根据您的问题描述，您在使用 DBMS_SCHEDULER 创建了两个作业（JOB_INSERT_RZ 和 JOB_INSERT_RZ1），但只有 JOB_INSERT_RZ 的状态是 NULL，而 JOB_INSERT_RZ1 的状态是正常的。唯一的区别在于这两个作业的 start_date 参数不同。

问题分析

从您提供的信息来看，JOB_INSERT_RZ 的 start_date 设置为一个远未来的日期（2026-08-05 12:00:00），而 JOB_INSERT_RZ1 的 start_date 设置为当前时间（SYSTIMESTAMP）。这种情况可能导致 JOB_INSERT_RZ 在创建时没有立即生效，因此其状态显示为 NULL。

解决方案

  1. 检查作业的状态：

    • 您可以使用以下查询来检查作业的状态和相关日志，以便获取更多信息。
      SELECT JOB_NAME, ENABLED, NEXT_RUN_DATE, STATE, LAST_START_DATE 
FROM DBA_SCHEDULER_JOBS;

  2. 启用作业：

    • 如果 JOB_INSERT_RZ 的 STATE 仍然是 NULL，您可以尝试手动启用它。
      BEGIN
  DBMS_SCHEDULER.ENABLE(name => 'JOB_INSERT_RZ');
END;
/

  3. 设置合理的 start_date：

    • 如果 start_date 设置得太远未来，可能会导致作业无法立即启动。您可以尝试将 start_date 设置为一个更近的时间点。
      BEGIN
  DBMS_SCHEDULER.CREATE_JOB (
    job_name        => 'JOB_INSERT_RZ',
    job_type        => 'STORED_PROCEDURE',
    job_action      => 'INSERT_RZ',
    start_date      => SYSTIMESTAMP,
    repeat_interval => 'FREQ=DAILY; INTERVAL=1',
    enabled         => TRUE);
END;
/

  4. 检查数据库日志：

    • 检查数据库的日志文件，查看是否有任何与 DBMS_SCHEDULER 相关的错误或警告信息。
      SELECT * FROM DBA_SCHEDULER_JOB_LOG WHERE JOB_NAME = 'JOB_INSERT_RZ';

可能的原因

  • 未来时间：start_date 设置为一个远未来的日期，作业不会立即启动，因此状态可能显示为 NULL。
  • 调度器未启用：确保 DBMS_SCHEDULER 已经启用并且正在运行。
  • 权限问题：确保执行这些操作的用户具有足够的权限。

如果上述步骤仍然不能解决问题，请提供更多详细信息或联系 OceanBase 的技术支持以获取进一步的帮助。

检索到的文档如下:

  1. 物化视图日志
  2. CREATE TABLE
  3. V$OB_SQLSTAT
3 个赞
#5

看看看看

1 个赞
#6

万能小助手

#7

SHOW VARIABLES like ‘version_comment’; 查一下版本信息 是社区版的mysql模式么？

2 个赞
#8

谢谢分享，很有帮助

1 个赞
#9

obclient(root@sys)[oceanbase]> show variables like ‘version_comment’;
±----------------±--------------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
±----------------±--------------------------------------------------------------------------------------------------------------+
| version_comment | OceanBase 4.2.5.7 (r107120012026060515-afcb8326c0d1b6baf51ddfd227ed0826eddca723) (Built Jun 5 2026 17:55:30) |
±----------------±--------------------------------------------------------------------------------------------------------------+
1 row in set (0.002 sec)
是商业版的oracle模式

1 个赞
#10

66

#11

job指定的运行日期是未来日期的话，state为null不影响，到时间会自动调度的，已验证，谢谢大家！

1 个赞
#12

谢谢小助手，学习到了

#13

今天又学到了。

#14

根本原因在 start_date 的写法。TO_TIMESTAMP('2026-08-05 12:00:00', ...) 返回的是不带时区的时间戳，OceanBase 会按会话时区（SESSIONTIMEZONE）解释它；而 12:00 相对你建 JOB 的时刻已是过去（或经时区换算后变成"已错过"的时点）。调度器要求首次运行时间不能早于当前时间，于是把这个 JOB 判为 missed 并忽略，表现为 STATE=NULL、从未执行（NEXT_RUN_DATE 停在过去的 12:00）。

对照的 JOB_INSERT_RZ1 用 SYSTIMESTAMP（自带 +08:00 时区且=当前时刻），首次运行=现在，立即进入 SCHEDULED。

修复：改用 SYSTIMESTAMP，或 TO_TIMESTAMP_TZ('... +08:00','... TZH:TZM') 显式带时区；建议同时指定 end_date。已建的 JOB 可用 DBMS_SCHEDULER.SET_ATTRIBUTE 改 start_date/end_date，或 DROP 后重建。

1 个赞
#15

学习了。

#16

谢谢小助手，学习到了