DBMS_JOB vs DBMS_SCHEDULER

What is the difference开发者_高级运维 between DBMS_JOB and DBMS_SCHEDULER ?

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_scheduler is more robust and fully-featured than dbms_job and includes the following features that dbms_job does not have :

• 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

Features in releases after 10g Release 1 include :

• 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)

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.

See this Ask Tom thread for more.

Listed next are some of the benefits that DBMS_SCHEDULER has over 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

• 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

Listed next are some of the advantages of using 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)

• 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

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!

What happens? And what does that mean for your jobs in 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.

See: DBMS_JOB – Behavior Change in Oracle 19c during upgrade