这是最常见的调度程序问题之一。在这里，我们列出了一些常见问题及其解决方案。
1）job_queue_processes可能太低（这是最常见的问题）。job_queue_processes的值限制了可以在给定时间运行的dbms_scheduler和dbms_job作业的总数。要检查是否存在这种情况，请使用sql>从v$ parameter中选择值，其中name=’job_queue_processes’;检查job_queue_processes的当前值；然后检查正在运行的作业数。sql>从dba_scheduler_running_jobs中 选择count（ ）。 sql >_从dba_jobs_running中_选择count（ ）；
如果这是问题所在，则可以使用sql> alter system set 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中选择count（*）。
如果这是问题，则可以使用sql> execdbms_scheduler.set_scheduler_attribute（’max_job_slave_processes’，null）增加数量或将其为NULL。
3）会话数可能太低此参数可随时限制会话数。每个Scheduler作业需要2个会话。要检查这是否是问题，请使用sql>从v $ parameter中选择值，其中name =’sessions’;检查当前值。然后使用sql> v $ session中的count（*）检查当前会话数；
如果数字太接近，则可以使用sql> alter system set job_queue_processes = 200;来增加最大值。
4）您最近是否应用了时区更新补丁或将数据库升级到具有较新的时区信息的版本？如果在更新时区信息时跳过了任何步骤，则作业可能无法运行。要检查是否是这种情况，请尝试执行sql>，从sys.scheduler $ _job中选择*；和sql> select * from sys.scheduler $ _window; 并确保它们完好无误。
如果它发出时区警告，请重新应用升级或时区补丁程序，确保遵循所有步骤。
5）数据库是否以受限模式运行？如果数据库以受限模式运行，则不会运行任何作业（除非您使用11g并使用ALLOW_RUNS_IN_RESTRICTED_MODE属性）。要进行检查，请使用sql>从v$ instance选择登录名；
如果登录受到限制，则可以使用sql> ALTER SYstem DISABLE RESTRICTED SESSION来禁用受限模式。
6）作业是否计划在发生故障的实例上运行？
您可以通过查看是否为作业设置了instance_id（检查dba_scheduler_jobs视图）来进行检查，如果是，则应检查该实例是否启动。
7）作业是否计划在尚未在任何实例上启动的服务上运行？
您可以通过检查作业指向哪个job_class，然后检查该类是否指向服务来进行检查。如果是这样，请确保已在至少一个正在运行的实例上启动该服务。您可以使用dbms_service.start_service在实例上启动服务。
8）资源管理器是否对限制性资源计划有效？
如果实施了限制性资源计划，则调度程序作业可能没有分配足够的资源，因此它们可能无法运行。您可以通过执行以下操作检查哪些资源计划有效
如果没有有效的计划或有效的计划是INTERNAL_PLAN，则资源管理器无效。如果资源管理器有效，则可以通过执行以下操作将其禁用
sql>更改系统集resource_manager_plan =’‘;
9）调度程序是否已禁用？这不是受支持的操作，但是可能有人已经这样做了。要对此进行检查，请执行sql>从dba_scheduler_global_attribute中选择值，其中attribute_name=’SCHEDULER_DISABLED’
如果此查询返回TRUE，则可以使用sql> execdbms_scheduler.set_scheduler_attribute（’scheduler_disabled’，’false’）;来解决此问题。
1）首先要检查的时区是使用sql> select owner，job_name，next_run_date fromdba_scheduler_jobs调度的作业的时区；
如果作业在错误的时区中，则它们可能无法在预期的时间运行。如果next_run_date使用绝对时区偏移量（如+08：00）而不是命名时区（如US / PACIFIC），则如果实行夏令时，作业可能无法按预期运行-它们可能早或晚运行一小时。
2）可能是在预定运行该作业时，可能暂时达到了上述几个限制之一，从而导致该作业被延迟。检查上述限制是否足够高，如果可能，请在延迟作业期间检查它们。
3）可能达到上述限制之一的一个可能原因是维护窗口可能已生效。维护窗口是属于名为MAINTENANCE_WINDOW_GROUP的窗口组的Oracle Scheduler窗口。在计划的维护窗口期间，使用作业运行多个维护任务。这可能会导致上述限制之一被击中，并且用户作业将被延迟。有关更多信息，请参阅管理指南（第24章）。
要获取维护窗口的列表，请使用sql>选择* from dba_scheduler_wingroup_members;。
要查看Windows何时运行，请使用sql>从dba_scheduler_windows中选择*；
要解决此问题，您可以增加限制，也可以重新安排维护时段以在更方便的时间运行。
诊断其他问题
如果这些都不起作用，那么您可以采取一些进一步的步骤来尝试找出正在发生的事情。
1）检查告警日志中是否有错误。如果数据库在分配内存时遇到问题或磁盘空间不足，或者发生了其他灾难性错误，则应首先解决这些问题。您可以使用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');
602392714
清零编程群