|Oracle® Database Administrator's Guide
11g Release 2 (11.2)
Part Number E17120-11
|PDF · Mobi · ePub|
This section discusses the Scheduler architecture, and describes:
Figure 28-6 illustrates how jobs are handled by the database.
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
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, 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.
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
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.
See Also:"Scheduler Data Dictionary Views" for job coordinator administration and "Using the Scheduler in Real Application Clusters Environments" for Oracle RAC information
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.
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.
Look for new work (if none, they go to sleep).
The Scheduler dynamically sizes the slave pool as required.
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.
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.
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.