这是最常见的调度程序问题之一。
这里我们列出了一些常见问题及其解决方案。
1）job_queue_processes可能太低（这是最常见的问题）
job_queue_processes的值限制了dbms_scheduler的总数
和 dbms_job 作业可以在给定时间运行。
要检查是否是这种情况，请检查当前值
job_queue_processes 与
SQL> 从 v$parameter 中选择值，其中 name='job_queue_processes';
然后查看正在运行的作业数量
SQL> 选择计数(）来自 dba_scheduler_running_jobs；
SQL> 选择计数(）来自 dba_jobs_running；
如果这是问题，您可以使用增加参数
SQL> 更改系统设置 job_queue_processes=1000;
2）max_job_slave_processes可能太低
如果此参数不为 NULL，则它会限制 dbms_scheduler 作业的数量
一次运行。要检查这是否是问题所在，请检查当前
价值利用
SQL> 从 dba_scheduler_global_attribute 选择值
其中 attribute_name='MAX_JOB_SLAVE_PROCESSES';
然后查看正在运行的作业数量
SQL> 从 dba_scheduler_running_jobs 选择计数（*）；
如果这是问题，您可以增加数字或使用 NULL 来删除它
SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3）会话可能太低
该参数限制任何时候的会话数量。每个调度程序作业
需要 2 次会议。要检查这是否是问题所在，请检查当前
价值利用
SQL> 从 v$parameter 中选择值，其中 name='sessions';
然后使用检查当前会话数
SQL> 从 v$session 中选择 count(*) ；
如果数字太接近，您可以使用增加最大值
SQL> 更改系统设置 job_queue_processes=200;
4) 您最近是否应用了时区更新补丁或升级了数据库
到具有更新时区信息的版本？如果您跳过任何步骤
更新时区信息，作业可能无法运行。要检查是否有此
是这种情况尝试做
SQL> 从 sys.scheduler$_job 选择*；
和
SQL> 从 sys.scheduler$_window 选择*；
并确保它们顺利完成。
如果抛出时区警告，请重新应用升级或
时区补丁确保遵循所有步骤。
5) 数据库是否在受限模式下运行？
如果数据库在受限模式下运行，则不会运行任何作业（除非
您使用的是 11g 并使用 ALLOW_RUNS_IN_RESTRICTED_MODE 属性）。
检查此用途
SQL> 从 v$instance 选择登录名；
如果登录受到限制，您可以使用禁用限制模式
SQL> ALTER SYSTEM 禁用受限会话；
6) 作业是否计划在已关闭的实例上运行？
您可以通过查看是否为作业设置了instance_id（检查dba_scheduler_jobs视图）来检查这一点，如果是这样，您应该检查该实例是否已启动。
7) 作业是否计划在尚未在任何实例上启动的服务上运行？
您可以通过检查作业指向的 job_class ，然后检查该类是否指向服务来检查这一点。如果是，请确保该服务已在至少一个正在运行的实例上启动。您可以使用 dbms_service.start_service 在实例上启动服务。
8) 资源经理是否实施了限制性资源计划？
如果限制性资源计划生效，调度程序作业可能没有分配足够的资源，因此它们可能无法运行。您可以通过执行以下操作来检查哪些资源计划有效
SQL> 从 V$RSRC_PLAN 选择名称；
如果没有有效的计划或有效的计划是 INTERNAL_PLAN，则资源管理器无效。如果资源管理器有效，您可以通过执行以下操作来禁用它
SQL>更改系统设置resource_manager_plan = '';
9) 调度程序是否被禁用？这不是受支持的操作
但无论如何，有可能有人已经做到了。要检查这一点，请执行以下操作：
SQL> 从 dba_scheduler_global_attribute 选择值，其中 attribute_name='SCHEDULER_DISABLED'
如果此查询返回 TRUE 那么您可以使用以下方法修复此问题
SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
作业可能迟到的原因
1）首先要检查的是安排作业的时区
SQL> 从 dba_scheduler_jobs 选择所有者、作业名称、下一个运行日期；
如果作业位于错误的时区，它们可能不会按预期运行
时间。如果 next_run_date 使用绝对时区偏移量（例如
+08:00）而不是指定时区（如美国/太平洋），那么工作可能不会
如果夏令时生效，则按预期运行 - 它们可能运行一个小时
早或晚。
2) 可能在作业计划运行时，多个作业之一
可能暂时达到上述限制，导致作业延迟。
检查上述限制是否足够高，如果可能的话，在期间检查它们
作业被延迟的时间。
3) 可能达到上述限制之一的一个可能原因是
维护窗口可能已生效。维护窗口是 Oracle
属于名为的窗口组的调度程序窗口
MAINTENANCE_WINDOW_GROUP。在计划的维护时段内，多个
维护任务是使用作业运行的。这可能会导致列出的限制之一
以上将受到打击并且用户作业将被延迟。请参阅管理指南以获取更多信息
关于这一点（第 24 章）。
要获取维护时段列表，请使用
SQL> 从 dba_scheduler_wingroup_members 选择*；
要查看 Windows 何时运行，请使用
SQL> 从 dba_scheduler_windows 选择*；
要解决此问题，您可以增加限制或重新安排维护
windows 在更方便的时间运行。
诊断其他问题
如果这些都不起作用，您可以采取一些进一步的步骤来尝试
弄清楚发生了什么事。
1）检查alert日志中是否有错误。如果数据库是
分配内存时遇到问题或磁盘空间不足或任何其他情况
发生了灾难性错误，您应该首先解决这些错误。你可以
使用以下命令查找警报日志的位置
SQL> 从 v$parameter 中选择值，其中 name = 'background_dump_dest';
警报日志将位于此目录中，名称以“alert”开头。
2) 检查是否有作业协调器跟踪文件，如果有，则检查是否有
包含任何错误。如果存在，它将位于
“background_dump_dest”目录，您可以像上面一样找到它并查看
类似于 SID-cjq0_nnnn.trc 。如果这里有任何错误，他们可能会
提示作业未运行的原因。
3) 如果上述任一情况表明 SYSAUX 表空间（调度程序存储其日志表的位置）已满，则可以使用 dbms_scheduler.purge_log 过程清除旧日志条目。
4) 查看当前是否有窗口打开。如果有，您可以尝试关闭它，看看是否有帮助。
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5）尝试运行一个简单的运行一次作业，看看它是否运行
SQL>begin
dbms_scheduler.create_job (
job_name => 'test_job',
job_type => 'plsql_block',
job_action => 'null;',
enabled => true);
end;
/
SQL> -- wait a while
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB';
6) 如果简单的一次性作业未运行，您可以尝试按如下方式重新启动调度程序。
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE');
SQL> alter system set job_queue_processes=0;
SQL> exec dbms_ijob.set_enabled(FALSE);
SQL>
SQL> alter system flush shared_pool;
SQL> alter system flush shared_pool;
SQL>
SQL> exec dbms_ijob.set_enabled(TRUE);
SQL> alter system set job_queue_processes=99;
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');
