Scheduler Architecture

This section discusses the Scheduler architecture, and describes:

The Job Table
The Job Coordinator
How Jobs Execute
After Jobs Complete
Using the Scheduler in Real Application Clusters Environments

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

Figure 28-6 Scheduler Components

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, under the control of the database, controls and starts job slaves, making use of the information in the job table.

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 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.

Job Coordinator Actions

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.

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

Maximum Number of Scheduler Job Processes

The coordinator automatically determines how many job slaves to start based on CPU load and the number of outstanding jobs. The JOB_QUEUE_PROCESSES initialization parameter can be used to limit the number of job slaves that the Scheduler can start.

How Jobs Execute

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 picked for processing, the job slave does the following:

Gathers all the metadata needed to run the job, for example, program arguments and privilege information.
Starts a database session as the owner of the job, starts a transaction, and then starts executing the job.
Once the job is complete, the slave commits and ends the transaction.
Closes the session.

After Jobs Complete

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 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 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.