12.2. Scheduler Architecture

Understanding how to use the Scheduler begins with understanding the underlying architecture upon which the Scheduler functionality is built. This is not to say that you have to be able to name every locking mechanism and memory structure used in the Scheduler, any more than a person needs to know the ignition sequence of their car in order to drive it. Rather, it implies that a high-level knowledge of the underlying Scheduler processes will help you create more logical Scheduler objects and enable you to troubleshoot problems associated with the Scheduler.

In these sections, you will learn about

  • The job table, which houses all the active jobs within the database

  • The job coordinator, a key Oracle process that ensures that jobs are being run on schedule

  • Job slaves, processes that carry out the execution of jobs under the guidance of the job coordinator

  • The architecture in Real Application Cluster (RAC) environments and how it differs only slightly from a stand-alone database environment

12.2.1. The Job Table

The Scheduler job table is the master container for all enabled jobs in the database. This table stores information about all jobs, including the objects referenced by the job, the owner of the job, and the next run date. It also stores statistical information about jobs such as the number of times the job has run and the number of times the job has failed. It also contains the STATE column that contains the current state of the job (for example, RUNNING, SCHEDULED, BROKEN).

The information stored in the job table can be viewed through the *_SCHEDULER_JOBS view. For example, the following query will show the state of all jobs in the table, as well as their next run date:

SQL> select owner, job_name, state
  2  from dba_scheduler_jobs;

OWNER      JOB_NAME             STATE
---------- -------------------- ------------
SYS        PURGE_LOG            SCHEDULED
SYS        GATHER_STATS_JOB     RUNNING

As you can see in this example, the GATHER_STATS_JOB is currently running, while the PURGE_LOG job is scheduled to run at some point in the future. If you really want to know when the PURGE_LOG job will run, you could include the NEXT_RUN_DATE column in your query and see exactly when it will run next.

12.2.2. The Job Coordinator

The job coordinator is an Oracle background process with the responsibility of ensuring that jobs are run on schedule. The job coordinator regularly queries the job table and copies job information to a memory cache for improved performance when the job is executed.

The Oracle database itself monitors job schedules and starts the job coordinator process (if it is not already started) when a job needs to be executed. The job coordinator pulls the job information from the memory cache and passes it to a job slave (described in the next section) process for execution.

The job coordinator controls all aspects of the job slave pool of processes, so it can remove dormant slave processes and spawn new processes as needed to meet the needs of the Scheduler.

12.2.3. The Job Slave Processes

Job slave processes are tasked with carrying out the execution of job programs assigned to them by the job Scheduler. When a job slave receives the job information from the coordinator, it sets to work collecting all the metadata that it needs to carry out the request. This metadata includes things such as the program arguments and privilege information.

When it is ready to execute the program, the job slave creates a new session as the owner of the job, starts a transaction within the session, and then executes the job. When the job is complete, the transaction is committed and the session is closed by the job slave. Next, the slave performs the following actions:

  • Update the STATUS column to a value of COMPLETED in the job table for the current job.

  • Update the RUN_COUNT column to increment the current value by 1 in the job table for the current job.

  • Insert an entry into the job log table.

  • Look for any new work that needs to be done.

If no new work is found, the job slave process will sleep until it is called again by the coordinator or until it is removed from the system by the job coordinator.

12.2.4. RAC Considerations

The Scheduler architecture in an Oracle Real Application Cluster (RAC) environment is the same as in a stand-alone instance, with the following exceptions:

  • Each instance in the cluster will have its own job coordinator.

  • The job coordinators can communicate with one another to share information.

  • Jobs can be defined with a service affinity (they should run on a specific service) as opposed to an instance affinity (they should run on a specific instance). If a job is assigned to a service consisting of two instances, even if one instance is down, the other can execute the job normally.

Aside from these exceptions, the Scheduler architecture in a RAC environment is the same as described previously.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset