Scheduler Architecture - Oracle 10g

This section discusses the Scheduler’s architecture, and describes:

  • The Job Table
  • The Job Coordinator
  • How Jobs Execute
  • Job Slaves
  • Using the Scheduler in RAC Environments

Scheduler Components

Scheduler Components

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, a type of job called transient is available and is the default. Jobs created as transient are deleted by background process after the jobs are finished. You can, of course, choose to use the persistent type of job, which allows for jobs to be kept for additional logging purposes.

The Job Coordinator

The job coordinator is a background process (cjqNNN) that is automatically started when jobs must be run, or windows must be opened. It is automatically brought down after a sustained period of Scheduler inactivity. 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 You do not need to set when 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 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:

  • update the entry in the job table to the COMPLETED status
  • insert an entry into the job log table
  • update the run 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 RAC Environments

All Scheduler functionality performs the same when using RAC as in a single -instance environment. Just as in other environments, the Scheduler in a RAC environment uses one job table for each database and one job coordinator for each instance.

RAC Architecture and the Scheduler

RAC Architecture and the Scheduler

The job coordinators communicate with each other to keep information current.

Service Affinity when Using the Scheduler

The Scheduler enables you to specify the service on 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.

Service Affinity and the Scheduler

Service Affinity and the Scheduler

you could change the properties of the services and the Scheduler will automatically recognize the change. Each job class maps to a service. If a service is not specified, the job class will belong to a default service.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Oracle 10g Topics