Search Results user_export




Overview
Explore in AI Chat

Overview

SYS.DBMS_JOB is the Oracle-supplied PL/SQL package that provides the legacy job scheduling interface for the database. Within Oracle E-Business Suite 12.1.1 and 12.2.2, it is the foundational scheduling mechanism on which many concurrent request submission, interface polling, and background maintenance routines were historically built. The package allows a session to submit a PL/SQL block for asynchronous execution, assign it a run date, define a repeat interval, and control the job lifecycle (change, remove, run, or mark broken) without direct manipulation of the underlying scheduler tables.

The package is owned by SYS and reports a status of VALID in the ETRM repository. Its API classification is OTHER, and it exposes 14 documented procedures and functions. Although Oracle Corporation has long positioned DBMS_SCHEDULER as the strategic replacement for DBMS_JOB, the older package remains present and valid in EBS releases because internal components — including DBMS_IREFRESH, DBMS_ISCHED, DBMS_SNAPSHOT, and even DBMS_SCHEDULER itself — retain dependencies on it. In the ETRM metadata, DBMS_JOB is referenced by nine other packages, confirming that it is a foundational utility rather than an application-specific one.

Key Procedures and Functions

The documented API surface consists of procedures that manage the complete lifecycle of a scheduled job:

  • SUBMIT — Creates a new job, associating a PL/SQL block with an initial execution date and an interval expression, and returns the job number to the caller.
  • ISUBMIT — Submits a job with a caller-supplied job number rather than one generated by the package, useful for deterministic naming.
  • REMOVE — Deletes an existing job so that it will no longer be executed by the job queue.
  • CHANGE — Modifies the attributes of a previously submitted job, including the executable block, next run date, interval, or instance affinity.
  • WHAT — Returns the PL/SQL block currently associated with a given job.
  • NEXT_DATE — Retrieves or sets the next date on which a job is scheduled to execute.
  • INTERVAL — Retrieves or sets the interval expression that governs how a job reschedules itself after each run.
  • INSTANCE — Retrieves or assigns the Real Application Clusters instance on which the job is permitted to run.
  • BROKEN — Marks a job as broken (or repairs it), preventing repeated failed executions from consuming job queue resources.
  • RUN — Forces immediate execution of a job regardless of its scheduled next date.
  • USER_EXPORT — Generates the PL/SQL text required to recreate a job, supporting migration between environments.
  • BACKGROUND_PROCESS — Reports the number of job queue background processes configured and available.
  • IS_JOBQ — Indicates whether the current session is running inside a job queue process, allowing application code to detect background execution context.

Tables Accessed

The ETRM documentation for this object records no tables accessed directly through APPS synonyms. DBMS_JOB operates exclusively against its own SYS-owned dictionary tables — principally the job definition and job queue dictionary structures that store job numbers, the WHAT block, NEXT_DATE, INTERVAL, BROKEN flag, and instance affinity. Because these objects reside in the SYS schema and are not exposed as APPS synonyms, application code interacts with them solely through the package's documented procedures. The referenced-by metadata lists only package-level dependencies (STANDARD, DBMS_AQADM_SYS, DBMS_IREFRESH, DBMS_ISCHED, DBMS_I_INDEX_UTL, DBMS_JOB, DBMS_PCLXUTIL, DBMS_PRVTAQIP, DBMS_SCHEDULER, DBMS_SNAPSHOT, and DBMS_UTILITY), with no application tables cited.

Usage Notes

DBMS_JOB is typically invoked from PL/SQL rather than directly from EBS forms. Standard patterns include submitting a job at form or concurrent program initialization, scheduling interface or interface-error polling routines, and driving periodic data cleanup or index maintenance. A database initialization parameter governs the number of job queue processes available to execute submitted jobs; if that value is zero, submitted jobs remain queued and never run, a common source of EBS troubleshooting activity. In EBS 12.1.1 and 12.2.2, DBMS_SCHEDULER is increasingly used for new scheduling work, but DBMS_JOB remains valid and available. Custom code that submits jobs should expose the returned job number for later CHANGE, BROKEN, or REMOVE calls, and should wrap submissions in error handling because failures to enqueue are silent at the call site. Because the package is owned by SYS and is referenced by numerous internal components, it should never be modified or replaced; extensions should be confined to application-level wrappers.