oracle DBMS_JOB 与 DBMS_SCHEDULER
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4152111/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
DBMS_JOB vs DBMS_SCHEDULER
提问by kupa
What is the difference between DBMS_JOB and DBMS_SCHEDULER ?
DBMS_JOB 和 DBMS_SCHEDULER 有什么区别？
回答by MKU
From other forums:
来自其他论坛：
Although dbms_job still exists in 10g and 11g, Oracle recommends the use of dbms_scheduler in releases 10g and up. No new features are being added to dbms_job and you will likely quickly run into its limitations.
尽管 dbms_job 在 10g 和 11g 中仍然存在，但 Oracle 建议在 10g 及更高版本中使用 dbms_scheduler。dbms_job 中没有添加任何新功能，您可能很快就会遇到它的局限性。
dbms_scheduler is more robust and fully-featured than dbms_job and includes the following features that dbms_job does not have :
dbms_scheduler 比 dbms_job 更健壮和功能齐全，并包括以下 dbms_job 不具备的功能：
- logging of job runs (job history)
- simple but powerful scheduling syntax (similar to but more powerful than cron syntax)
- running of jobs outside of the database on the operating system
- resource management between different classes of jobs
- use of job arguments including passing of objects into stored procedures
- privilege-based security model for jobs
- naming of jobs and comments in jobs
- stored, reusable schedules
- 作业运行的日志记录（作业历史）
- 简单但强大的调度语法（类似于但比 cron 语法更强大）
- 在操作系统上的数据库之外运行作业
- 不同类别作业之间的资源管理
- 使用作业参数，包括将对象传递到存储过程
- 作业的基于特权的安全模型
- 作业的命名和作业中的注释
- 存储的、可重用的时间表
Features in releases after 10g Release 1 include :
10g 第 1 版之后的版本中的功能包括：
- dependencies between job units (10gR2 and up)
- scheduling based on financial calendars and fiscal quarters (10gR2 and up)
- event based jobs which run when an event is received (10gR2 and up)
- running of jobs on remote machines (11gR1 and up)
- e-mail notifications on job events of interest (10gR2 and up)
- starting a job based on arrival of a file (10gR2 and up)
- 作业单元之间的依赖关系（10gR2 及更高版本）
- 基于财务日历和财务季度（10gR2 及更高版本）的调度
- 在接收到事件时运行的基于事件的作业（10gR2 及更高版本）
- 在远程机器上运行作业（11gR1 及更高版本）
- 有关感兴趣的工作事件的电子邮件通知（10gR2 及更高版本）
- 根据文件的到达启动作业（10gR2 及更高版本）
回答by Tony Andrews
One difference to be aware of is that unlike DBMS_JOB, DBMS_SCHEDULER performs a commit, which makes it unsuitable for some uses. It is also rather cumbersome for simpler requirements. While DBMS_JOB will no longer be enhanced, it is unlikely to ever be desupported, as there must be thousands of systems that are using it and rely on the way it works, including not performing an implicit commit of the transaction from which it was called.
需要注意的一个区别是，与 DBMS_JOB 不同，DBMS_SCHEDULER 执行提交，这使其不适用于某些用途。对于更简单的要求，它也相当麻烦。虽然 DBMS_JOB 将不再增强，但它不太可能被取消支持，因为肯定有成千上万的系统在使用它并依赖它的工作方式，包括不执行调用它的事务的隐式提交。
See this Ask Tom threadfor more.
有关更多信息，请参阅此 Ask Tom 主题。
回答by Valeh A?ayev
Listed next are some of the benefits that DBMS_SCHEDULER has over cron:
下面列出的是 DBMS_SCHEDULER 相对于 cron 的一些好处：
? Can make the execution of a job dependent on the completion of another job
? 可以使一个作业的执行依赖于另一个作业的完成
? Robust resource balancing and flexible scheduling features
? 强大的资源平衡和灵活的调度功能
? Can run jobs based on a database event
? 可以基于数据库事件运行作业
? DBMS_SCHEDULER syntax works the same regardless of the operating system
? 无论操作系统如何，DBMS_SCHEDULER 语法都相同
? Can run status reports using the data dictionary
? 可以使用数据字典运行状态报告
? If working in clustered environment, no need to worry about synchronizing multiple cron tables for each node in the cluster
? 如果在集群环境下工作，无需担心为集群中的每个节点同步多个cron表
Listed next are some of the advantages of using cron:
下面列出了使用 cron 的一些优点：
? Easy to use, simple, tried and true
? 易于使用、简单、久经考验且真实
? Almost universally available on all Linux/Unix boxes; for the most part, runs nearly identically regardless of the Linux/Unix platform (yes, there are minor differences)
? 几乎在所有 Linux/Unix 机器上普遍可用；大多数情况下，无论 Linux/Unix 平台如何，运行方式几乎相同（是的，有细微差别）
? Database agnostic; operates independently of the database and works the same regardless of the database vendor or database version
? 数据库不可知；独立于数据库运行，无论数据库供应商或数据库版本如何，工作方式都相同
? Works whether the database is available or not
? 无论数据库是否可用都有效
回答by Roy Latham
I know this is an old thread, but this seems relevant.
我知道这是一个旧线程，但这似乎相关。
With the upgrade to Oracle Database 19c there will be a conversion of jobs under the hood of the old DBMS_JOB interface. No worries – relax!
随着升级到 Oracle Database 19c，旧 DBMS_JOB 接口下的作业将发生转换。不用担心 - 放松！
What happens? And what does that mean for your jobs in DBA_JOBS?
发生什么了？这对您在 DBA_JOBS 中的工作意味着什么？
First of all, you can't prevent or skip the migration under the scheduler's control. But there is also no reason to do so.
首先，您不能阻止或跳过调度程序控制下的迁移。但也没有理由这样做。
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
What this means is: You can still use DBMS_JOB but under the cover we are using DBMS_SCHEDULER. The internal procedures have been changed. Your calls will work the same way, but DBMS_JOB is now a legacy interface to the DBMS_SCHEDULER.
这意味着：您仍然可以使用 DBMS_JOB，但实际上我们使用的是 DBMS_SCHEDULER。内部程序已更改。您的调用将以相同的方式工作，但 DBMS_JOB 现在是 DBMS_SCHEDULER 的旧接口。
See: DBMS_JOB – Behavior Change in Oracle 19c during upgrade
