You can use Oracle Scheduler to schedule jobs in a multitenant container database (CDB).
Before using Oracle Scheduler with a CDB, meet the following requirements:
You understand how to configure and manage a CDB.
You understand how to use Oracle Scheduler to schedule jobs in a non-CDB.
DBMS_SCHEDULER Invocations in a CDB
Most scheduler calls work the same way as they do in non-CDBs, except for two scheduler global attributes.
JOB_QUEUE_PROCESSES initialization parameter specifies the maximum number of job slaves per instance that can be created for the execution of
DBMS_JOB jobs and Oracle Scheduler (
DBMS_SCHEDULER) jobs. The range of values is
To limit job slaves in a CDB environment, you can set
JOB_QUEUE_PROCESSES in the following locations:
JOB_QUEUE_PROCESSESto the maximum number of slave processes that Scheduler can use simultaneously in the entire database instance.
0in the CDB root, then
DBMS_JOBand Oracle Scheduler jobs cannot run in the root or any PDB, regardless of the
JOB_QUEUE_PROCESSESsetting at the PDB level.
JOB_QUEUE_PROCESSESto the maximum number of simultaneous jobs for this PDB. The actual number depends on the resources assigned by Resource Manager and the demand in other containers. When multiple PDBs request jobs, Oracle Scheduler attempts to give all PDBs a fair share of the processes.
0in a PDB, then
DBMS_JOBand Oracle Scheduler jobs cannot run in this PDB, regardless of the
JOB_QUEUE_PROCESSESsetting in the CDB root.
You must set all global Oracle Scheduler attributes at the PDB level. For example, if you set the
EMAIL_SENDER attribute in the root database using
DBMS_SCHEDULER.SET_ATTRIBUTE, then it applies to the jobs that run in the root, not the jobs running in a specific PDB. If you choose a new
EMAIL_SENDER for a PDB, then you must set the global attribute in this PDB.
Oracle Database Reference to learn more about
Job Coordinator and Slave Processes in a CDB
The major CDB-related changes are to the job coordinator process.
In a non-CDB, the coordinator looks at all jobs that are ready to run, picks a subset of them to run, and assigns them to job slaves. It also opens and closes windows, which changes the resource plan in effect for the database.
That is essentially what happens inside a CDB except for the following:
Jobs are selected from all PDBs
The coordinator looks at the root database and all the child PDBs and selects jobs based on the job priority, the job scheduled start time, and the availability of resources to run the job. The latter criterion depends on the consumer group of the job and the resource plan currently in effect. The coordinator makes no attempt to be fair to every PDB. The only way to ensure that jobs from a PDB are not starved is to allocate enough resources to it.
Windows are open in the PDB and root database levels
In a non-CDB, only one window can be open at any given time. In a CDB, there are two levels of windows. At the PDB level, windows can be used to set resource plans that allocate resources among consumer groups belonging to that PDB. At the root database level, windows can allocate resources to different PDBs. Therefore, at any time, there can be a window open in the root database and one in each PDB.
Job slave switches to the specific PDB it belongs to
The job slaves are essentially the same as in a non-CDB, except that when a slave executes a job, it switches to the PDB that the job belongs to and then executes it. The rest of the code is essentially unchanged.
DBMS_JOB and DBMS_SCHEDULER
You can use
DBMS_JOB within a PDB only if you grant the
CREATE JOB privilege to the schemas that submit
DBMS_JOB interface is implemented using
DBMS_SCHEDULER. For this reason, Oracle recommends that you switch from
For the scheduler, the coordinator selects jobs to run from every PDB. Also, for the scheduler, the slave process switches into a PDB before executing a job; otherwise, the code is essentially unchanged.
Oracle Database Administrator’s Guide for information about support for
Processes to Close a PDB
If a PDB is closed with the immediate option, then the coordinator terminates jobs running in the PDB, and the jobs must be recovered before they can run again.
In an Oracle RAC database, the coordinator can, in most cases, recover the jobs on another instance where that PDB is open. So, if the coordinator on the first instance can find another instance where the PDB is still open, it moves the jobs there. In certain cases, moving the jobs to another instance may not be possible. For example, if the PDB in question is not open anywhere else, the jobs cannot be moved. Also, moving a job to another instance is not possible when the job has the
INSTANCE_ID attribute set. In this case the job cannot run until the PDB on that instance is open again.
In a non-Oracle RAC case, the question of moving jobs does not arise. Terminated jobs can only be recovered after the PDB is opened again.
New and Changed CDB Views
Some CDB views are specific to CDBs, whereas others have a CDB-specific column.
GV$views have a
CON_IDcolumn that identifies a container whose data is represented by a
CDB_*row. In non-CDBs, the
CDB_*views correspond to all Scheduler
In a PDB, these views only show objects visible through a corresponding
DBA_*view, but all objects are visible in the root. The
CDB_*view contains all columns found in a given
DBA_*view and the column (
CON_ID). In non-CDBs, this column is