The Legacy Obituaries

Notices of desupport & departureOracle Database → AzureTuesday, 29 September 2026The Coroner’s ReportsAbout this paper

DBMS_SCHEDULER

pre-11.2 · scheduler

Survived, partially.

✓ certified by the mortician

In life

Oracle Scheduler, exposed through the DBMS_SCHEDULER package, is a full job scheduler inside the database. A job combines a program (PL/SQL block, stored procedure, operating-system executable, SQL script or backup script), a schedule expressed in calendaring syntax or triggered by an event, and optional destinations and credentials. Around jobs sit job classes tied to the Resource Manager, maintenance windows, dependency chains with branching rules, file watchers, and remote or multi-destination execution through Scheduler agents.

Migrations care because no Azure target offers this breadth in one place. Simple recurring PL/SQL jobs map to SQL Server Agent on Managed Instance, Elastic Jobs for Azure SQL Database or the pg_cron extension on PostgreSQL, but chains, windows, resource plans, external executables and event-driven jobs spread across orchestration services such as Data Factory, Functions or Logic Apps. Job logging and run history views also have no direct counterpart.

The feature is fully supported and not deprecated. Since 19c it is also the engine behind legacy DBMS_JOB jobs, which are converted into Scheduler jobs at upgrade, so a Scheduler inventory taken on 19c or later should include those converted jobs.

Cause of departure

Not deprecated by Oracle. Listed here because Azure offers no clean equivalent.

Obituary

DBMS_SCHEDULER, born before 11.2, arranged Oracle’s scheduled work through jobs, programs, chains, windows, event triggers, external jobs and resource classes. It handled duties ranging from SQL execution to conditional workflows.

Its Azure passage was blocked because Azure SQL Database has no SQL Server Agent and no internal scheduler. T-SQL scheduling moves to Elastic Jobs, while other work requires external services and redesign.

It is survived by Azure SQL Database, only by workaround; Azure SQL Elastic Jobs, partly; pg_cron extension on PostgreSQL Flexible Server, partly; and SQL Server Agent on SQL Managed Instance, partly. None inherits its full estate, though each keeps a respectable portion of the timetable.

Survived by

Azure SQL Elastic Jobs partial effort L

Applies to Oracle 11.2, 12.1, 12.2, 18c, 19c, 21c, 23ai, 26ai

Elastic Jobs provide scheduled, retried, multi-database T-SQL execution for Azure SQL Database, which covers the core of DBMS_SCHEDULER for SQL work and adds dynamic enumeration of targets that Oracle lacks. Everything else in the scheduler (external programs, file watchers, event-driven jobs, chains, windows, credentials for OS accounts) has to be rebuilt in Azure Functions, Logic Apps or Data Factory.

  • Separate scheduler jobs into pure-SQL jobs and jobs touching the OS, files or network.
  • Create the elastic job agent and target groups; grant the agent's managed identity rights in each target database.
  • Recreate SQL jobs as job steps with retry and timeout settings; use output tables for results that Oracle jobs logged to tables.
  • Implement non-SQL jobs as timer-triggered Azure Functions or Data Factory pipelines.
  • Replace job chains with pipeline orchestration since Elastic Jobs have no cross-job dependencies.

Complications

major Elastic Jobs run only T-SQL job steps, evaluate all schedules in UTC, retry failed steps (so scripts must be idempotent), purge history older than 45 days, and cannot use a Hyperscale or auto-pausing serverless database as the job database.
· General Purpose, Business Critical, Hyperscale · microsoft Elastic jobs in Azure SQL Database

pg_cron extension (PostgreSQL Flexible Server) partial effort M

Applies to Oracle 11.2, 12.1, 12.2, 18c, 19c, 21c, 23ai, 26ai

pg_cron covers time-based SQL jobs with cron syntax, second-level intervals and per-database scheduling, and logs runs in a table. It has no programs, chains, windows, event triggers, external jobs or resource classes, and it runs jobs as the scheduling user, so PL/SQL that relied on those scheduler objects needs an external orchestrator.

  • Enable pg_cron (allowlist, shared_preload_libraries, restart) on the Flexible Server.
  • Convert job bodies to PL/pgSQL procedures and schedule them with cron.schedule_in_database.
  • Approximate calendaring strings with cron expressions; jobs that need last-day-of-month can use the dollar sign syntax.
  • Move EXECUTABLE and file-watcher jobs to Azure Functions or Data Factory.
  • Query cron.job_run_details for history and set cron.timezone to match the old server time zone.

Complications

major On Azure Database for PostgreSQL Flexible Server, pg_cron can only be loaded through shared_preload_libraries (CREATE EXTENSION alone fails), must be allowlisted, stores metadata in the database named by cron.database_name, and cron.schedule_in_database cannot take a non-null username because that requires superuser rights the service does not grant.
· microsoft Considerations when using extensions in Azure Database for PostgreSQL flexible server
minor pg_cron has no job chains or dependencies, runs at most one instance of a given job at a time (queuing overlapping runs), and interprets schedules in GMT unless cron.timezone is changed.
· community pg_cron README

SQL Server Agent (on SQL Managed Instance) partial effort M

Applies to Oracle 11.2, 12.1, 12.2, 18c, 19c, 21c, 23ai, 26ai

SQL Server Agent is the closest instance-hosted scheduler: jobs, multi-step workflows, schedules, operators and email notifications all exist. DBMS_SCHEDULER concepts without an Agent equivalent are calendaring strings with complex rules, job classes and resource-manager windows, event-based jobs raised from Advanced Queuing, chains with conditional branching, and external or remote-database job types, because Managed Instance Agent supports only T-SQL, SSIS and some replication step types.

  • Export scheduler metadata (DBA_SCHEDULER_JOBS, _PROGRAMS, _SCHEDULES, _CHAINS) and classify each job by job_type.
  • Convert PLSQL_BLOCK and STORED_PROCEDURE jobs to T-SQL job steps; route EXECUTABLE and EXTERNAL_SCRIPT jobs to Azure Functions or Data Factory.
  • Rebuild simple chains as multi-step jobs with on-success/on-failure step flow.
  • Recreate schedules; verify calendaring strings that used BYWEEKNO, INTERSECT or exclusions manually.
  • Configure the single permitted Database Mail profile for notifications.

Complications

major On Managed Instance, Agent does not support CmdExec, PowerShell, Analysis Services, merge replication or Queue Reader job steps, proxies, alerts, pager or NetSend notifications, idle-CPU schedules or multi-server (MSX/TSX) administration, and email notification requires a single Database Mail profile named AzureManagedInstance_dbmail_profile.
· General Purpose, Next-gen General Purpose, Business Critical · microsoft T-SQL differences between SQL Server and Azure SQL Managed Instance
minor Azure SQL Managed Instance includes SQL Server Agent, which is always running and cannot be disabled, with T-SQL, SSIS and transactional-replication job steps supported.
· General Purpose, Next-gen General Purpose, Business Critical · microsoft T-SQL differences between SQL Server and Azure SQL Managed Instance

Azure SQL Database workaround effort L

Applies to Oracle 11.2, 12.1, 12.2, 18c, 19c, 21c, 23ai, 26ai

There is nothing inside an Azure SQL Database that schedules work: SQL Server Agent is not part of the service. Scheduling therefore has to come from outside the database, either Elastic Jobs for T-SQL or Azure Functions, Logic Apps and Data Factory for anything else. Applications that created scheduler jobs dynamically from PL/SQL need redesign.

  • Decide per job between Elastic Jobs (T-SQL only) and an external orchestrator.
  • Remove PL/SQL that calls DBMS_SCHEDULER.CREATE_JOB at run time; expose the work as a stored procedure instead.
  • Use Azure Functions timer triggers or Data Factory tumbling-window triggers for schedules that need non-SQL steps.
  • Centralize monitoring in Azure Monitor alerts rather than DBA_SCHEDULER_JOB_RUN_DETAILS.

Complications

blocker SQL Server Agent is not available in Azure SQL Database; Microsoft's automation overview directs T-SQL job scheduling to Elastic Jobs and lists Agent only for SQL Server and Azure SQL Managed Instance.
· General Purpose, Business Critical, Hyperscale, Basic, Standard, Premium · microsoft Automation in Azure SQL overview (Elastic jobs vs SQL Agent)

Notices of correction

  1. oracle Oracle Scheduler Concepts (Administrator's Guide 19c) · Database Administrator's Guide 19c · read 2026-09-26
  2. oracle Support for DBMS_JOB (Administrator's Guide 19c) · Database Administrator's Guide 19c · read 2026-09-26
  3. microsoft Elastic jobs in Azure SQL Database · page updated 2026-02-26 · read 2026-09-26
  4. microsoft Automation in Azure SQL overview (Elastic jobs vs SQL Agent) · page updated 2025-11-18 · read 2026-09-26
  5. microsoft Azure Functions overview · page updated 2026-09-21 · read 2026-09-26
  6. microsoft Considerations when using extensions in Azure Database for PostgreSQL flexible server · page updated 2026-08-12 · read 2026-09-26
  7. community pg_cron README · pg_cron 1.6 · read 2026-09-26
  8. microsoft T-SQL differences between SQL Server and Azure SQL Managed Instance · page updated 2026-09-09 · read 2026-09-26
  9. microsoft Compare SQL Database Engine features: Azure SQL Database vs Azure SQL Managed Instance · page updated 2026-09-09 · read 2026-09-26

← All notices

DBMS_SCHEDULER — Legacy Obituaries