調研背景

因為在測試procedure+dbms_job組合的任務時，呼叫失敗（看著就是任務沒跑）。經過查詢資料庫引數，發現是JOB_QUEUE_PROCESS的值為0。

調研內容

本次調研資料主要來源為Oracle官方文件和MOS，以條目的形式展示JOB_QUEUE_PROCESS引數相關的資料。下面檢視展示的條目。

引數的作用

JOB_QUEUE_PROCESS指定了Oracle資料庫的每個instance在執行 DBMS_JOB和 DBMS_SCHEDULER任務時，能夠建立的最大的子任務數量。

引數允許的數值範圍

在 12.1及之前版本，引數允許的預設值是0到1000。在12.2及18c版本中，引數允許的預設值是0到4000。

引數在不同版本中的預設值

在9i和10g中，預設值是0；在11g和12cR1版本中，預設值為1000，在12cR2和18c版本中，預設值為4000。

這裡就很尷尬了，誰把我的資料庫引數改成0的（資料庫版本是11.2.0.4 ）

修改引數值的方法

job_queue_processes引數值可以動態修改，預設是scope=both

alter system set job_queue_processes=<integer>;

在RAC資料庫中，執行命令

alter system set job_queue_processes=<integer> sid='*';

引數值為0的情況

在10g和11gR1中，將JOB_QUEUE_PROCESSES設定為0只會導致DBMS_JOB作業無法執行，但DBMS_SCHEDULER作業未受影響且仍將執行。

從11gR2開始，將JOB_QUEUE_PROCESSES設定為0會導致DBMS_SCHEDULER和DBMS_JOB作業都無法執行。

將JOB_QUEUE_PROCESS設定為0將禁用下列功能以及使用Oracle Scheduler或DBMS_JOB的任何其他功能或特性：

高階複製(Advanced Replication)使用Oracle Scheduler進行資料重新整理。
Oracle AQ（ Oracle Streams Advanced Queuing ）使用Oracle Scheduler進行訊息傳播。
物化檢視（Materialized Views）使用Oracle Scheduler進行自動重新整理。

注意：Oracle資料庫在升級模式下會覆蓋job queue設定，以禁用排程任務。因此，升級Oracle資料庫時無需更改引數設定。

確保引數的合理性

如果需要將JOB_QUEUE_PROCESSES設定為較低的值，則應考慮以下因素：

理想情況下，JOB_QUEUE_PROCESSES值應大於資料庫中執行的所有併發作業。讓JOB_QUEUE_PROCESSES大於排程的作業總數（使用scheduler + dbms_job）是個好主意。這將確保即使某些作業超過其常規執行持續時間，我們也不會耗盡JOB_QUEUE_PROCESSES。

另外，由下列方法生成的排程程式作業，也可能會產生相應的程式開銷：

任何高階複製（Advanced Replication ）重新整理
Oracle AQ流式訊息傳輸
物化檢視（Materialized Views）重新整理
DBMS_REDEFINITION資料表重定義

除此之外，可能還有一些可以手動或透過某些第三方工具在資料庫中執行的臨時作業。 JOB_QUEUE_PROCESSES也應該滿足這些。

多租戶資料庫的引數特性

在12.1.0.1中，job_queue_process是容器資料庫（CDB）可修改引數（全域性級別）。

在12.1.0.2中，job_queue_process引數不是CDB可修改的; 相反的，它是PDB可以修改的，但是每個pdb都無法正確使用自己的job_queue_processes值。

從12.2開始，JOB_QUEUE_PROCESSES是PDB可修改的：

如果ROOT中的job_queue_processes為0，則在所有PDB中禁用Scheduler，包括ROOT。
如果在除ROOT之外的特定PDB中將job_queue_processes設定為0，則僅在該PDB中禁用Scheduler。

調研結果

如果要保證系統高峰期Oracle也能執行各種任務，那麼需要將JOB_QUEUE_PROCESS引數設定為一個合理值。採用“技術手段獲取”+“經驗判斷”相結合的方式，是一種不錯的solution。

各位讀者朋友也可關注作者微信公眾號“IT技術佳餚”，與作者交流。

【Oracle】簡單引數也有講究，JOB_QUEUE_PROCESS引數調研

相關文章