參數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.sqlDECLARE   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        =>   '  beginINSERT 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_jobPL/SQL procedure successfully completed.-->查看job_queue_processes參數的值SQL> show parameter jobNAME                                 TYPE        VALUE------------------------------------ ----------- ------------------------------job_queue_processes                  integer     1-->此時和Job相關的進程一個，為ora_j000SQL> ho ps -ef | grep rac11g | grep ora_j | grep -v greporacle    9692     1  4 12:03 ?        00:00:01 ora_j000_rac11g1-->查看剛剛添加的job-->下面的NEXT_RUN_DATE在秒層級上稍有差異，其實在定義job時，這個是由於前面的for迴圈造成的延遲-->在此忽略這個細微的差異SQL> @jobsOWNER        JOB_NAME       ENABL JOB_CLASS                      NEXT_RUN_DATE------------ -------------- ----- ------------------------------ -----------------------------------SCOTT        JOB_1          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.33.000000 PM +08:00SCOTT        JOB_2          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.33.000000 PM +08:00SCOTT        JOB_3          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.33.000000 PM +08:00SCOTT        JOB_4          TRUE  DEFAULT_JOB_CLASS              19-MAR-13 12.21.34.000000 PM +08:00SCOTT        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:33JOB_2 20130319 12:22:35JOB_3 20130319 12:23:37JOB_4 20130319 12:24:39JOB_5 20130319 12:25:41

3、測試參數job_queue_processes大於1的情形

-->首先移除之前的jobSQL> ho more remove_job.sqlDECLARE   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_jobPL/SQL procedure successfully completed.-->此時設定job_queue_processes的值為6SQL> 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 greporacle    3477     1  9 12:29 ?        00:00:01 ora_j000_rac11g1oracle    3491     1  4 12:29 ?        00:00:00 ora_j001_rac11g1-->添加多個jobSQL> @add_jobPL/SQL procedure successfully completed.--> Author : Robinson--> Blog   : http://blog.csdn.net/robinson_0612SQL> @jobsOWNER                JOB_NAME    ENABL JOB_CLASS             NEXT_RUN_DATE-------------------- ----------- ----- --------------------- -----------------------------------SCOTT                JOB_1       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.55.000000 PM +08:00SCOTT                JOB_2       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00SCOTT                JOB_3       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00SCOTT                JOB_4       TRUE  DEFAULT_JOB_CLASS     19-MAR-13 12.31.56.000000 PM +08:00SCOTT                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 greporacle    7668     1  1 11:57 ?        00:00:01 ora_j000_rac11g1oracle    7678     1  0 11:57 ?        00:00:01 ora_j001_rac11g1oracle    7700     1  1 11:57 ?        00:00:01 ora_j002_rac11g1oracle    9230     1  0 11:57 ?        00:00:00 ora_j003_rac11g1oracle    9257     1  2 11:58 ?        00:00:01 ora_j005_rac11g1oracle    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:57JOB_1 20130319 12:32:58JOB_1 20130319 12:33:59JOB_2 20130319 12:31:58JOB_2 20130319 12:32:59JOB_2 20130319 12:34:00JOB_3 20130319 12:31:58JOB_3 20130319 12:32:59JOB_3 20130319 12:34:00JOB_4 20130319 12:31:59JOB_4 20130319 12:33:00JOB_4 20130319 12:34:01JOB_5 20130319 12:31:58JOB_5 20130319 12:32:59JOB_5 20130319 12:34:00-->從上面的查詢結果可知每一個job的上一次與下一次執行間隔基本保持在1分鐘-->不同job之間的每一次執行時間基本上是相同的，這與job_queue_processes為1時完全不一樣-->也就是說即使是job_5，基本上與job_1是同時執行，而不是像前面測試那樣前面所有的執行完後才被執行-->移除jobSQL> @remove_jobPL/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等。

 

更多參考:

有關Oracle RAC請參考
     使用crs_setperm修改RAC資源的所有者及許可權
     使用crs_profile管理RAC資源設定檔
     RAC 資料庫的啟動與關閉
     再說 Oracle RAC services
     Services in Oracle Database 10g
     Migrate datbase from single instance to Oracle RAC
     Oracle RAC 串連到指定執行個體
     Oracle RAC 負載平衡測試(結合伺服器端與用戶端)
     Oracle RAC 伺服器端串連負載平衡(Load Balance)
     Oracle RAC 用戶端串連負載平衡(Load Balance)
     ORACLE RAC 下非預設連接埠監聽配置(listener.ora tnsnames.ora)
     ORACLE RAC 監聽配置 (listener.ora tnsnames.ora)
     配置 RAC 負載平衡與容錯移轉
     CRS-1006 , CRS-0215 故障一例 
     基於Linux (RHEL 5.5) 安裝Oracle 10g RAC
     使用 runcluvfy 校正Oracle RAC安裝環境

有關Oracle 網路設定相關基礎以及概念性的問題請參考：
     配置非預設連接埠的動態服務註冊
     配置sqlnet.ora限制IP訪問Oracle
     Oracle 監聽器日誌配置與管理
     設定 Oracle 監聽器密碼(LISTENER)
     配置ORACLE 用戶端串連到資料庫

有關基於使用者管理的備份和備份恢複的概念請參考
     Oracle 冷備份
     Oracle 熱備份
     Oracle 備份恢複概念
     Oracle 執行個體恢複
     Oracle 基於使用者管理恢複的處理
     SYSTEM 資料表空間管理及備份恢複
     SYSAUX資料表空間管理及恢複
     Oracle 基於備份控制檔案的恢複(unsing backup controlfile)

有關RMAN的備份恢複與管理請參考
     RMAN 概述及其體繫結構
     RMAN 配置、監控與管理
     RMAN 備份詳解
     RMAN 還原與恢複
     RMAN catalog 的建立和使用
     基於catalog 建立RMAN儲存指令碼
     基於catalog 的RMAN 備份與恢複
     RMAN 備份路徑困惑
     使用RMAN實現異機備份恢複(WIN平台)
     使用RMAN遷移檔案系統資料庫到ASM
     linux 下RMAN備份shell指令碼
     使用RMAN遷移資料庫到異機

有關ORACLE體繫結構請參考
     Oracle 資料表空間與資料檔案
     Oracle 密碼檔案
     Oracle 參數檔案
     Oracle 聯機重做記錄檔(ONLINE LOG FILE)
     Oracle 控制檔案(CONTROLFILE)
     Oracle 歸檔日誌
     Oracle 復原(ROLLBACK)和撤銷(UNDO)
     Oracle 資料庫執行個體啟動關閉過程
     Oracle 10g SGA 的自動化管理
     Oracle 執行個體和Oracle資料庫(Oracle體繫結構)