scheduler_jobs 不跑全面检查

------------------ 数据库400多天不重启导致进程不存在，也可能导致问题-----

SELECT job_name, enabled FROM dba_scheduler_jobs;
  
select owner, job_name, job_style, job_creator,job_action, start_date, repeat_interval,last_start_date, last_run_duration, next_run_date,comments ,instance_id 
from DBA_SCHEDULER_JOBS  a 
--where job_name ='' 

select * from Gv$instance

1.job_queue_processes设置太小
1) job_queue_processes may be too low (this is the most common problem) The value of job_queue_processes limits the total number of dbms_scheduler
and dbms_job jobs that can be running at a given time. To check whether this is the case check the current value of job_queue_processes with

SQL> select value from v$parameter where name='job_queue_processes';

!Then check the number of running jobs

SQL> select count(*) from dba_scheduler_running_jobs;
SQL> select count(*) from dba_jobs_running;

!If this is the problem you can increase the parameter using

SQL> alter system set job_queue_processes=1000;

2.max_job_secondary_processes设置太小
如果这个值设置不会空，那么就会限制同一时间dbms_scheduler jobs运行的数量

2) max_job_secondary_processes may be too low. If this parameter is not NULL then it limits how many dbms_scheduler jobs can
be running at a time. To check whether this is the problem, check the current value using

SQL> select value from dba_scheduler_global_attribute
where attribute_name='MAX_JOB_SECONDARY_PROCESSES';
-- Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;
-- If this is the problem you can increase the number or just NULL it out using
SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_secondary_processes',null)

3.session参数设置的太小
该参数限制任何时候的回话，每个计划程序作业需要两个回话，要检查是否是问题所在
3) Sessions may be too low. This parameter limits the number of sessions at any time. Every Scheduler job requires 2 sessions. To check whether this is the problem, check the current valule using

SQL> select value from v$parameter where name='sessions';
-- Then check the current number of sessions using
SQL> select count(*) from v$session ;
-- If the numbers are too close you can increase the maximum using
SQL> alter system set job_queue_processes=200;

4.检查时区是否最近被更新
如果完成时有时区告警，需要更新数据库时区
4) Have you recently applied a timezone update patch or upgraded the database to a version with newer timezone information? If you skipped any steps when
updating the timezone information, jobs may not run. To check whether this is the case try doing
SQL> select * from sys.scheduler$_job;
and
SQL> select * from sys.scheduler$_window;

and make sure they finish without errors.

If it throws a timezone warning, reapply the upgrade or
timezone patch making sure to follow all the steps.

 
5.检查数据库是否以受限模式打开
5) Is the database running in restricted mode? If the database is running in restricted mode then no jobs will run (unless you are using 11g and use the ALLOW_RUNS_IN_RESTRICTED_MODE attribute).
To check this use
SQL> select logins from v$instance ;
-- If logins are restricted you can disable the restricted mode using
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6) Is the job scheduled to run on an instance which is down?
6.检查job是否在以关闭的实例上运行
You can check this by seeing whether instance_id is set for the job (check the dba_scheduler_jobs view) and if so you should check whether that instance is up.
select owner, job_name, job_style, job_creator,job_action, start_date, repeat_interval,last_start_date, last_run_duration, next_run_date,comments ,instance_id 
from DBA_SCHEDULER_JOBS  a 
 

7.检查job是否在未启动呢的服务上运行
select * from dba_scheduler_job_classes
如下所示，两个job_class对应的服务名分别是orcl、orcl1.这里的orcl1在测试的时候进行了关闭处理。在实际的测试中，如果对应的service无效或者是未启动、删除等操作，
定时调度job是无法自动进行调度的，且无法生成log日志，但是手工可以执行，且dba_scheduler_job_log.additional_info=REASON=“manually run”

7) Is the job scheduled to run on a service that has not been started in any instances?
You can check this by checking what job_class job points to and then checking whether that class points to a service. 
If it does, make sure the service has been started on at least one running instance. You can start a service on an instance using dbms_service.start_service.

8.检查是否有资源管理限制
如果限制性资源计划生效，调度程序作业可能没有分配足够的资源，因此可能无法运行。可以通过执行以下操作来检查什么资源计划有效
SQL> select name from V$RSRC_PLAN;
如果没有有效的计划，或者有效的计划是内部计划，则资源管理器无效。如果资源管理器有效，可以通过执行以下操作来禁用它：
SQL> alter system set resource_manager_plan = ‘’;

8) Is the Resource Manager in effect with a restrictive resource plan?
If a restrictive resource plan is in effect, scheduler jobs may not have sufficient resources allocated so they may not run. You can check what resource plan is in effect by doing

SQL> select name from V$RSRC_PLAN;
If no plan is in effect or the plan in effect is INTERNAL_PLAN then the resource manager is not in effect. If the resource manager is in effect you can disable it by doing

SQL> alter system set resource_manager_plan = '';
 

9.检查调度程序是否被禁用
9) Has the Scheduler been disabled? This is not a supported action but it is possible that someone has done it anyway. To check this do

SQL> select value from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED';
If this query returns TRUE then you can fix this using
SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
 

Top Reasons Why Scheduler Jobs May Runs Late:

1.检查调度任务默认的时区
如果作业在错误的时区，它们可能无法在预期时间运行。如果下一个运行日期使用的是绝对时区偏移量（如+08:00），而不是指定的时区（如美国/太平洋），则作业可能不会
如果夏令时生效，按预期运行——它们可能提前或延迟运行一小时。
SQL> select owner, job_name, next_run_date from dba_scheduler_jobs ;

1) The first thing to check is the timezone that the job is scheduled with

SQL> select owner, job_name, next_run_date from dba_scheduler_jobs ;
If the jobs are in the wrong timezone they may not run at the expected time. If the next_run_date is using an absolute timezone offset (like+08:00) instead of a named timezone (like US/PACIFIC) then the jobs may not
run as expected if daylight savings is in effect - they may run an hour early or late.

 
2.资源限制导致job延迟
在job延迟执行期间，检查上述的一些资源是否达到瓶颈
2) It may be that at the time the job was scheduled to run, one of the several limits above may have been temporarily reached causing the job to be delayed.
Check if the limits above are high enough and if possible check them during the time that the job is being delayed.

 
3.达到资源限制的之一可能是Oracle的维护窗口已经生效
3) One possible reason that one of the above limits may be hit is that a maintenance window may have come into effect. Maintenance windows are Oracle
Scheduler windows that belong to the window group named MAINTENANCE_WINDOW_GROUP. During a scheduled maintenance window, several
maintenance tasks are run using jobs. This may cause one of the limits listed above to be hit and user jobs to be delayed. 

To get a list of maintenance windows to use
SQL> select * from dba_scheduler_wingroup_members;

To see when the windows run use
SQL> select * from dba_scheduler_windows;

To fix this you can either increase the limits or reschedule the maintenance
windows to run at more convenient times.

Diagnosing Other Problems:

 
1.检查alert日志是否有报错
确定数据库在分配内存、磁盘空间或其他内存不足引发的一系列问题，通过以下命令找到alert日志位置
If none of the above works, here are some further steps you can take to try to figure out what is going on.

1) Check whether there are any errors in the alert log. If the database is having trouble allocating memory or has run out of disk space or any other
catastrophic errors have occurred, you should resolve those first. You can find the location of the alert log by using

SQL> select value from v$parameter where name = 'background_dump_dest';

The alert log will be in this directory with a name starting with "alert".

2) Check whether if a job coordinator trace file and if it does, check if it contains any errors. If this exists, it will be located in the 'background_dump_dest' directory which you can find above and will look
something like SID-cjq0_nnnn.trc. If there are any errors here they may hint at why jobs are not running.

3) If either of the above indicates that the SYSAUX tablespace (where the scheduler stores its logging tables) is full, you can use the dbms_scheduler.purge_log procedure to clear out old log entries.

 
4.检查当前打开窗口，默认为空
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where attribute_name='CURRENT_OPEN_WINDOW';

ATTRIBUTE_NAME       VALUE
-------------------- --------------------
CURRENT_OPEN_WINDOW
如果当前窗口默认不为空，且为某个时间点，如果此时的时间不匹配可能导致计划任务无法执行。通过以下命令处理

SQL> exec DBMS_SCHEDULER.close_window (‘WEEKNIGHT_WINDOW’);
4) See if there is a window currently open. If there is, you can try closing it to see if that helps. 

SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW'); 

5)try running a simple run-once job and see if it runs

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) If a simple run-once job doesnt run, you can try restarting the scheduler as follows.

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');
If nothing is running then you should check your permissions, in particular, the user that the job runs as must have executed access on $ORACLE_HOME/bin and all parent directories. So for e.g., if your $ORACLE_HOME is /opt/oracle/db then you would have to make sure that

chmod a+rx /opt
chmod a+rx /opt/oracle
chmod a+rx /opt/oracle/db
chmod a+rx /opt/oracle/db/bin