DBMS_JOB vs DBMS_SCHEDULER

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.

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)

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