DBMS_JOB 与 DBMS_SCHEDULER

Question

DBMS_JOB 和 DBMS_SCHEDULER 之间有什么区别？

Answer 1

来自其他论坛：

虽然 dbms_job 仍然存在于 10g 和 11g 中，但 Oracle 建议在 10g 及更高版本中使用 dbms_scheduler。 dbms_job 中没有添加任何新功能，您可能很快就会遇到它的限制。

dbms_scheduler 比 dbms_job 更健壮、功能更齐全，并且包含 dbms_job 没有的以下功能：

• 记录作业运行（作业历史记录）
• 简单但强大的调度语法（类似于 cron 语法，但比 cron 语法更强大）
• 在外部运行作业操作系统上的数据库
• 不同类别作业之间的资源管理
• 使用作业参数，包括将对象传递到存储过程
• 基于权限的作业安全模型
• 作业命名和
• 存储的作业中的注释，可重用的计划

10g 第 1 版之后的版本中的功能包括：

• 作业单元（10gR2 及更高版本）之间的依赖关系
• 基于财务日历和会计季度（10gR2 及更高版本）的调度 基于
• 的作业，在收到事件时运行（10gR2 及更高版本）
• 在远程计算机上运行作业（11gR1 及更高版本）
• 事件 有关感兴趣的作业事件（10gR2 及更高版本）的邮件通知
• 根据文件到达启动作业（10gR2 及更高版本）

Answer 2

需要注意的一个区别是，与 DBMS_JOB 不同，DBMS_SCHEDULER 执行提交，这使得它不适合某些用途。对于比较简单的需求来说也比较麻烦。虽然 DBMS_JOB 将不再得到增强，但它不太可能被取消支持，因为肯定有数千个系统正在使用它并依赖于它的工作方式，包括不执行调用它的事务的隐式提交。

请参阅此“询问 Tom”主题 了解更多。

Answer 3

接下来列出的是 DBMS_SCHEDULER 相对于 cron 的一些优点：

• 可以使一个作业的执行依赖于另一个作业的完成

• 强大的资源平衡和灵活的调度功能

• 可以基于数据库事件

• 无论操作系统如何，DBMS_SCHEDULER 语法的工作方式都是相同的

• 可以使用数据字典运行状态报告

• 如果在集群环境中工作，无需担心为集群中的每个节点同步多个 cron 表

接下来列出的是使用 cron 的一些优点：

• 易于使用、简单、经过验证且真实。

• 几乎在所有 Linux/Unix 机器上都可用。在大多数情况下，无论 Linux/Unix 平台如何，运行几乎相同（是的，存在细微差别）

。独立于数据库运行，无论数据库供应商或数据库版本如何，其工作方式都是相同的

• 无论数据库是否可用，都可以工作

Answer 4

我知道这是一个旧线程，但这似乎相关。

升级到 Oracle Database 19c 后，旧 DBMS_JOB 接口下的作业将会发生转换。不用担心——放松！

会发生什么？这对您在 DBA_JOBS 中的工作意味着什么？

首先，您无法在调度程序的控制下阻止或跳过迁移。但也没有理由这样做。

During the 19c upgrade for each job in DBMS_JOB a corresponding entry will be created with DBMS_SCHEDULER
The old DBMS_JOB interface still works. But using it will always create a corresponding entry in the scheduler
The check in preupgrade.jar is only checking for inconsistencies or any issues

这意味着：您仍然可以使用 DBMS_JOB，但实际上我们正在使用 DBMS_SCHEDULER。内部程序已更改。您的调用将以相同的方式工作，但 DBMS_JOB 现在是 DBMS_SCHEDULER 的旧接口。

请参阅：DBMS_JOB – 行为更改升级期间的 Oracle 19c