Skip Headers
Oracle® Database Administrator's Guide
11g Release 2 (11.2)

Part Number E17120-05
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

Scheduler Architecture

This section discusses the Scheduler architecture, and describes:

Figure 28-6 illustrates how jobs are handled by the database.

Figure 28-6 Scheduler Components

Description of Figure 28-6 follows
Description of "Figure 28-6 Scheduler Components"

The Job Table

The job table is a container for all the jobs, with one table for each database. The job table stores information for all jobs such as the owner name or the level of logging. You can find this information in the *_SCHEDULER_JOBS views.

Jobs are database objects, and therefore, can accumulate and take up too much space. To avoid this, job objects are automatically dropped by default after completion. This behavior is controlled by the auto_drop job attribute.

See "Scheduler Data Dictionary Views" for the available job views and administration.

The Job Coordinator

The job coordinator background process (cjqNNN) is automatically started and stopped on an as-needed basis. At database startup, the job coordinator is not started, but the database does monitor whether there are any jobs to be executed, or windows to be opened in the near future. If so, it starts the coordinator.

As long as there are jobs or windows running, the coordinator continues to run. After there has been a certain period of Scheduler inactivity and there are no jobs or windows scheduled in the near future, the coordinator is automatically stopped.

When the database determines whether or not to start the job coordinator, it takes the service affinity of jobs into account. For example, if there is only one job scheduled in the near future and this job belongs to a job class that has service affinity for only two out of the four Oracle RAC instances, only the job coordinators for those two instances are started. See "Service Affinity when Using the Scheduler" for more information.

The job coordinator:

  • Controls and spawns the job slaves

  • Queries the job table

  • Picks up jobs from the job table on a regular basis and places them in a memory cache. This improves performance by reducing trips to the disk

  • Takes jobs from the memory cache and passes them to job slaves for execution

  • Cleans up the job slave pool when slaves are no longer needed

  • Goes to sleep when no jobs are scheduled

  • Wakes up when a new job is about to be executed or a job was created using the CREATE_JOB procedure

  • Upon database, startup after an abnormal database shutdown, recovers any jobs that were running.

You do not need to set the time that the job coordinator checks the job table; the system chooses the time frame automatically. The coordinator automatically determines how many job slaves to start based on CPU load and the number of outstanding jobs. In special scenarios, you can limit the maximum number of slaves that the coordinator starts by setting the MAX_JOB_SLAVE_PROCESSES parameter with the DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE procedure.

One job coordinator is used per instance. This is also the case in Oracle RAC environments.

See Also:

"Scheduler Data Dictionary Views" for job coordinator administration and "Using the Scheduler in Real Application Clusters Environments" for Oracle RAC information

How Jobs Execute

When a job is picked for processing, the job slave does the following:

  1. Gathers all the metadata needed to run the job, for example, program arguments and privilege information.

  2. Starts a database session as the owner of the job, starts a transaction, and then starts executing the job.

  3. Once the job is complete, the slave commits and ends the transaction.

  4. Closes the session.

Job Slaves

Job slaves actually execute the jobs you submit. They are awakened by the job coordinator when it is time for a job to be executed. They gather metadata to run the job from the job table.

When a job is done, the slaves do the following:

  • Reschedule the job if required.

  • Update the state in the job table to reflect whether the job has completed or is scheduled to run again.

  • Insert an entry into the job log table.

  • Update the run count, and if necessary, failure and retry counts.

  • Clean up.

  • Look for new work (if none, they go to sleep).

The Scheduler dynamically sizes the slave pool as required.

Using the Scheduler in Real Application Clusters Environments

In an Oracle Real Application Clusters (Oracle RAC) environment, the Scheduler uses one job table for each database and one job coordinator for each instance. The job coordinators communicate with each other to keep information current. The Scheduler attempts to balance the load of the jobs of a job class across all available instances when the job class has no service affinity, or across the instances assigned to a particular service when the job class does have service affinity.

Figure 28-7 illustrates a typical Oracle RAC architecture, with the job coordinator for each instance exchanging information with the others.

Figure 28-7 Oracle RAC Architecture and the Scheduler

Description of Figure 28-7 follows
Description of "Figure 28-7 Oracle RAC Architecture and the Scheduler"

Service Affinity when Using the Scheduler

The Scheduler enables you to specify the database service under which a job should be run (service affinity). This ensures better availability than instance affinity because it guarantees that other nodes can be dynamically assigned to the service if an instance goes down. Instance affinity does not have this capability, so, when an instance goes down, none of the jobs with an affinity to that instance can run until the instance comes back up. Figure 28-8 illustrates a typical example of how services and instances could be used.

Figure 28-8 Service Affinity and the Scheduler

Description of Figure 28-8 follows
Description of "Figure 28-8 Service Affinity and the Scheduler"

In Figure 28-8, you could change the properties of the services and the Scheduler automatically recognizes the change.

Each job class can specify a database service. If a service is not specified, the job class belongs to an internal service that is guaranteed to be mapped to every running instance.