Scheduler Architecture

The Job Table

The job table is a container for all the jobs, with one table per 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 can therefore 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 the job class to which this job belongs has service affinity for only two out of the four 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 avoiding going 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 when 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 to be started by the coordinator 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 RAC environments.

How Jobs Execute

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

1. Gathers all the metadata needed to run the job. As an example, arguments of the program 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:

• 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 count and retry count

• 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 a Real Application Clusters (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 27-7 illustrates a typical RAC architecture, with each instance's job coordinator exchanging information with the others.

Figure 27-7 RAC Architecture and the Scheduler

Description of "Figure 27-7 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 will be able to run until the instance comes back up. Figure 27-8 illustrates a typical example of how services and instances could be used.

Figure 27-8 Service Affinity and the Scheduler

Description of "Figure 27-8 Service Affinity and the Scheduler"

In Figure 27-8, you could change the properties of the services and the Scheduler will automatically recognize 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.