• 来自其他论坛：*

尽管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及更高版本）

需要注意的一个区别是，与DBMS_JOB不同，DBMS_SCHEDULER执行提交，这使得它不适合某些用途。对于较简单的要求，它也相当麻烦。虽然DBMS_JOB将不再增强，但它不太可能被取消支持，因为肯定有成千上万的系统正在使用它并依赖于它的工作方式。包括不执行从中调用它的事务的隐式提交。
更多信息请参见this Ask Tom thread。

下面列出的是DBMS_SCHEDULER相对于cron的一些优势：

·可以使一个作业的执行依赖于另一个作业的完成
·强大的资源平衡和灵活的调度功能
·可以基于数据库事件运行作业
· DBMS_SCHEDULER语法的工作方式与操作系统无关
·可以使用数据字典运行状态报告
·如果在集群环境中工作，无需担心为集群中的每个节点同步多个cron表

下面列出了使用cron的一些优点：

·易于使用，简单，久经考验和真实
·几乎普遍适用于所有Linux/Unix系统;在大多数情况下，无论使用何种Linux/Unix平台，运行方式几乎相同（是的，存在细微差异）
·数据库不可知;独立于数据库运行，无论数据库供应商或数据库版本如何，其工作方式都相同
·无论数据库是否可用都有效

我知道这是一个老线索，但这似乎相关。
升级到Oracle数据库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 – Behavior Change in Oracle 19c during upgrade