调研背景
因为在测试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技术佳肴”，与作者交流。
