This section discusses the Scheduler’s architecture, and describes:
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:
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:
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:
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
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
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.
Oracle 10g Related Interview Questions
|Oracle 10g Interview Questions||Oracle 9i Interview Questions|
|Oracle 8i Interview Questions||Informatica Interview Questions|
|PL/SQL Interview Questions||Oracle 11g Interview Questions|
|SQL Interview Questions||Oracle apps Interview Questions|
|Sybase Interview Questions||Oracle Apps ERP Interview Questions|
|Oracle 7.3 Interview Questions||Oracle Access Manager Interview Questions|
|Oracle Application Framework Interview Questions||Oracle Apps DBA Interview Questions|
Oracle 10g Related Practice Tests
|Oracle 10g Practice Tests||Oracle 9i Practice Tests|
|Oracle 8i Practice Tests||Informatica Practice Tests|
|PL/SQL Practice Tests||Oracle 11g Practice Tests|
|SQL Practice Tests||Oracle apps Practice Tests|
|Sybase Practice Tests||Oracle Apps ERP Practice Tests|
|Oracle 7.3 Practice Tests|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.