DBMS_JOB is the original PL/SQL job queue. A session submits an anonymous block together with a first run time and an interval expression, commits, and background job-queue processes execute it on that cadence. It predates Oracle Scheduler by many years and is still found in installation scripts and packaged applications, frequently created by code paths that nobody remembers.

Migrations care because each job is hidden scheduling state that does not appear in the schema DDL most tools extract. The interval is a free-form date expression rather than a calendar string, submission only takes effect on COMMIT, and jobs run with the submitting schema's privileges. All of that has to be rediscovered before it can be mapped onto Azure scheduling options.

Oracle's 12.2 Upgrade Guide lists the package as deprecated with DBMS_SCHEDULER as the replacement, and the 19c package reference says the package has been superseded and that support may be removed in a future release. It has not been desupported as of 26ai. Starting with 19c, an upgrade re-creates existing jobs as Scheduler jobs and DBMS_JOB survives only as a compatibility interface; schemas that submit jobs must hold the CREATE JOB privilege, and metadata problems surface as a JOB_TABLE_INTEGRITY precheck warning.

DBMS_JOB, born before 11.2, scheduled anonymous PL/SQL blocks and procedure calls at intervals. Its transactional submissions vanished obediently whenever the caller’s transaction rolled back.

Deprecated in 12.2 but not desupported, it remained functional through 26ai as a wrapper over DBMS_SCHEDULER. Reports of its 19c demise usually reflected the new CREATE JOB privilege requirement, whose absence produces ORA-27486, rather than an actual removal.

It is survived by Azure SQL Elastic Jobs, partly; pg_cron extension on PostgreSQL Flexible Server, partly; and SQL Server Agent on SQL Managed Instance, partly. Each requires medium effort, converted job bodies, and acceptance that the old transactional submission semantics did not make the journey.