参数job_queue_processes与Oracle jobs-阿里云开发者社区

Oracle jobs为Oracle开发人员和数据库管理员提供了数据库层面维护的极大便利性。对于Oracle jobs在Oracle 9i之前，是由dbms_jobs来实现，而到了10g之后，多出了dbms_scheduler方式。两者同样可以添加Oracle job，只不过dbms_scheduler的功能更为强大。在使用Oracle jobs时，我们不得不关注job_queue_processes参数，用于设定job队列可以启动的进程数。本文即是围绕此展开。

1、job_queue_processes参数

alter system set job_queue_processes= 0,,,1000

下面是11g reference的描述：
JOB_QUEUE_PROCESSES specifies the maximum number of job slaves per instance that can be created for the execution of DBMS_JOB jobs and Oracle Scheduler (DBMS_SCHEDULER) jobs. DBMS_JOB and Oracle Scheduler share the same job coordinator and job slaves, and they are both controlled by the JOB_QUEUE_PROCESSES parameter.

If the value of JOB_QUEUE_PROCESSES is set to 0, then DBMS_JOB jobs and Oracle Scheduler jobs will not run on the instance.If JOB_QUEUE_PROCESSES is set to a value in the range of 1 to 1000, then DBMS_JOB jobs and Oracle Scheduler jobs will run. The actual number of job slaves created for Oracle Scheduler jobs is auto-tuned by the Scheduler depending on several factors, including available resources, Resource Manager settings, and currently running jobs. However, the combined total number of job slaves running DBMS_JOB jobs and Oracle Scheduler jobs on an instance can never exceed the value of JOB_QUEUE_PROCESSES for that instance. The number of job slaves running Oracle Scheduler jobs is additionally limited to the value of the MAX_JOB_SLAVE_PROCESSES Scheduler attribute.

Advanced replication uses Oracle Scheduler for data refreshes. Oracle Streams Advanced Queuing uses Oracle Scheduler for message propagation. Materialized views use Oracle Scheduler for automatic refreshes. Setting JOB_QUEUE_PROCESS to 0 will disable these features as well as any other features that use Oracle Scheduler or DBMS_JOB.

a、从上面的描述可知，对于Oracle job进程，包含协调进程(主进程)以及奴隶进程(子进程)。
b、job_queue_processes取值范围为0到1000，总共可创建多少个job进程由job_queue_processes参数来决定。
c、当job_queue_processes大于1时，且并行执行job时，至少一个为协调进程。其总数不会超出job_queue_processes的值。
d、job_queue_processes参数的值为且DBMS_JOB与DBMS_SCHEDULER共享。
e、job_queue_processes参数，当设定该值为0的时候则任意方式创建的job都不会运行。
f、非零值的job_queue_processes，其job子进程数依赖于可用资源，资源配置方式以及当前运行的job数来自行调整。
g、此外对于Scheduler jobs方式还受限制于scheduler属性MAX_JOB_SLAVE_PROCESSES的设置。
h、可以通过DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE来设置max_job_slave_processes

2、测试参数job_queue_processes为1的情形

-->演示环境
SQL> select * from v$version where rownum<2;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

-->创建测试用表
CREATE TABLE tb_job
(
   job_name    VARCHAR2 (5),
   update_dt   VARCHAR2 (20)
);

-->添加多个Oracle job来并发执行
SQL> ho more add_job.sql
DECLARE
   job_name   VARCHAR2 (20);
BEGIN
   DBMS_OUTPUT.put_line ('Current sysdate is ' || TO_CHAR (SYSDATE, 'yyyymmdd hh24:mi:ss'));

   FOR i IN 1 .. 5
   LOOP
      job_name := 'JOB_' || TO_CHAR (i);
      sys.DBMS_SCHEDULER.create_job (
         job_name          => job_name,
         start_date        => sysdate+1/1440,
         repeat_interval   => 'freq = minutely; interval=1',
         end_date          => NULL,
         job_class         => 'DEFAULT_JOB_CLASS',
         job_type          => 'PLSQL_BLOCK',
         job_action        =>   '  
begin
INSERT INTO tb_job
      SELECT '''
                             || job_name
                             || ''', TO_CHAR (SYSDATE, ''yyyymmdd hh24:mi:ss'') FROM DUAL;
dbms_lock.sleep(60);
commit;
end;
',
         enabled           => true,
         comments          => 'my test job');
   END LOOP;
END;
/

SQL> @add_job

PL/SQL procedure successfully completed.

-->查看job_queue_processes参数的值
SQL> show parameter job

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes                  integer     1

-->此时和Job相关的进程一个，为ora_j000
SQL> ho ps -ef | grep rac11g | grep ora_j | grep -v grep
oracle    9692     1  4 12:03 ?        00:00:01 ora_j000_rac11g1

-->查看刚刚添加的job
-->下面的NEXT_RUN_DATE在秒级别上稍有差异，其实在定义job时，这个是由于前面的for循环造成的延迟
-->在此忽略这个细微的差异
SQL> @jobs

OWNER        JOB_NAME       ENABL JOB_CLASS                      NEXT_RUN_DATE
------------ -------------- ----- ------------------------------ -----------------------------------
SCOTT        JOB_1          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.33.000000 PM +08:00
SCOTT        JOB_2          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.33.000000 PM +08:00
SCOTT        JOB_3          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.33.000000 PM +08:00
SCOTT        JOB_4          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.34.000000 PM +08:00
SCOTT        JOB_5          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.34.000000 PM +08:00

-->job执行的情况，可以看到5个job被逐一执行
-->尽管我们定义时的NEXT_RUN_DATE相差1秒，而此时job的执行后则每一个相差1分钟
-->job_1与job_5相差4分多钟，这是由于我们定义了dbms_lock.sleep(60)为1分钟
-->其次可以看出由于只有一个job进程，因此每一个job是一个一个被执行
SQL> select * from tb_job;

JOB_N UPDATE_DT
----- --------------------
JOB_1 20130319 12:21:33
JOB_2 20130319 12:22:35
JOB_3 20130319 12:23:37
JOB_4 20130319 12:24:39
JOB_5 20130319 12:25:41

3、测试参数job_queue_processes大于1的情形

-->首先移除之前的job
SQL> ho more remove_job.sql
DECLARE
   job_name   VARCHAR2 (10);
BEGIN
   FOR i IN 1 .. 5
   LOOP
      job_name := 'JOB_' || TO_CHAR (i);
      sys.DBMS_SCHEDULER.drop_job (job_name, force => TRUE);
   END LOOP;
END;
/

SQL> @remove_job

PL/SQL procedure successfully completed.

-->此时设置job_queue_processes的值为6
SQL> alter system set job_queue_processes=6;

System altered.

-->清空测试用表
SQL> truncate table tb_job;

Table truncated.

-->此时Oracle为job启动了2个进程
SQL> ho ps -ef | grep rac11g | grep ora_j | grep -v grep
oracle    3477     1  9 12:29 ?        00:00:01 ora_j000_rac11g1
oracle    3491     1  4 12:29 ?        00:00:00 ora_j001_rac11g1

-->添加多个job
SQL> @add_job

PL/SQL procedure successfully completed.

--> Author : Robinson
--> Blog   : http://blog.csdn.net/robinson_0612

SQL> @jobs

OWNER                JOB_NAME    ENABL JOB_CLASS             NEXT_RUN_DATE
-------------------- ----------- ----- --------------------- -----------------------------------
SCOTT                JOB_1       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.55.000000 PM +08:00
SCOTT                JOB_2       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00
SCOTT                JOB_3       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00
SCOTT                JOB_4       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00
SCOTT                JOB_5       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00

-->片刻后可以看到job进程总数达到6个
SQL> ho ps -ef | grep rac11g | grep ora_j | grep -v grep
oracle    7668     1  1 11:57 ?        00:00:01 ora_j000_rac11g1
oracle    7678     1  0 11:57 ?        00:00:01 ora_j001_rac11g1
oracle    7700     1  1 11:57 ?        00:00:01 ora_j002_rac11g1
oracle    9230     1  0 11:57 ?        00:00:00 ora_j003_rac11g1
oracle    9257     1  2 11:58 ?        00:00:01 ora_j005_rac11g1
oracle    9353     1  7 11:59 ?        00:00:00 ora_j004_rac11g1          

-->查看表tb_job的情形                   
SQL> select * from tb_job order by 1,2;

JOB_N UPDATE_DT
----- --------------------
JOB_1 20130319 12:31:57
JOB_1 20130319 12:32:58
JOB_1 20130319 12:33:59
JOB_2 20130319 12:31:58
JOB_2 20130319 12:32:59
JOB_2 20130319 12:34:00
JOB_3 20130319 12:31:58
JOB_3 20130319 12:32:59
JOB_3 20130319 12:34:00
JOB_4 20130319 12:31:59
JOB_4 20130319 12:33:00
JOB_4 20130319 12:34:01
JOB_5 20130319 12:31:58
JOB_5 20130319 12:32:59
JOB_5 20130319 12:34:00

-->从上面的查询结果可知每一个job的上一次与下一次执行间隔基本保持在1分钟
-->不同job之间的每一次执行时间基本上是相同的，这与job_queue_processes为1时完全不一样
-->也就是说即使是job_5，基本上与job_1是同时执行，而不是像前面测试那样前面所有的执行完后才被执行

-->移除job
SQL> @remove_job

PL/SQL procedure successfully completed.

-->移除测试表
SQL> drop table tb_job purge;

Table dropped.

4、小结
a、job_queue_processes参数决定了job作业能够使用的总进程数。
b、当该参数为0值，任何job都不会被执行，建议合理设置该值且至少大于1。
c、对于job运行时间也应该尽量合理的设置间隔以及启动时间。
d、如果同一时间内运行的Job数很多，过小的参数值导致job不得不进行等待。而过大的参数值则消耗更多的系统资源。
f、对于存在依赖关系的job，尽可能将其进行合并到一个job中，如使用chain等。