Automating Tasks with the Scheduler

The main functionality of any enterprise scheduling system is the ability to schedule tasks to execute at a specific date and time. These can be recurring tasks that run at preset intervals or one-time tasks set to execute immediately or at some point in the future.

To achieve this functionality, the Scheduler uses several distinct components to specify scheduled tasks:

Jobs    A job instructs the Scheduler to run a specific program at a specific time on a specific date.

Programs    A program contains the code (or a reference to the code) such as PL/SQL code or a binary executable that needs to be run to accomplish a task. It can also contain parameters that should be passed to the program at runtime. A program can be stored as an independent object that can be referenced by many jobs.

Schedules    A schedule contains a start date, an optional end date, and a repeat interval. With these elements, an execution schedule can be calculated. A schedule can be stored as an independent object that can be referenced by many jobs.

Windows    A window identifies a recurring block of time during which a specific resource plan should be enabled to govern resource allocation for the database. For instance, the weekend may be classified as a maintenance window, and you can enable a resource plan that allocates the bulk of the system resources to administrative users.

Job classes    A job class is a logical method of classifying jobs with similar attributes. Job groups define specific attributes that will be inherited by all jobs assigned to the group. They also simplify management by allowing collections of jobs to be manipulated as one object.

Window groups    A window group is a logical method of grouping windows. They simplify the management of windows by allowing the members of the group to be manipulated as one object. Unlike job groups, window groups don’t set default characteristics for windows that belong to the group.

Chains    A chain consists of two or more Scheduler programs that are linked together to meet an objective. A chain is an implementation of dependency scheduling, where the outcome of one job determines which job or jobs will execute next.

These basic components make up the bulk of Oracle’s Scheduler facility. Their design encourages building flexible, reusable components shared by many scheduled jobs.

The Scheduler also offers a powerful and flexible calendaring syntax that is used to specify recurring task executions. This new syntax allows for the specification of complex date and time requirements. It also eliminates many of the shortcomings of DBMS_JOB, such as schedule creep (where the start time of a task was directly affected by the start time of the previous execution of that task).

Last, the Scheduler allows the execution of non-Oracle-related programs and scripts. This means that the Scheduler can be used not only to execute SQL and PL/SQL, but also operating-system executable programs. Therefore, most of your tasks can be scheduled in a common place.

564  Chapter 12  n  Using the Scheduler to Automate Tasks

Exploring the 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 the following sections, you will learn about these topics:

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

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

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

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. And it contains the STATE column, which 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

2from dba_scheduler_jobs;

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.

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.

The background process for the job coordinator is cjqNNN. There is one job-coordinator process per instance.

The Job-Slave Processes

Job-slave processes are tasked with carrying out the execution of job programs assigned to them by the 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:

NNUpdates the RUN_COUNT column to increment the current value by 1 in the job table for the current job. If necessary, updates the failure and retry count.

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.