Basic Scheduler Concepts

Programs

A Scheduler program object is a collection of metadata about what will be run by the Scheduler. It includes information such as the name of the program object, program action (for example, a procedure or executable name), program type (for example, PL/SQL and Java stored procedures or PL/SQL anonymous blocks) and the number of arguments required for the program.

A program is a separate entity from a job. Jobs run at a certain time or because a certain event occurred, and invoke a certain program. Jobs can be created that point to existing program objects, which means that different jobs can use the same program and run the program at different times and with different settings. Given the right privileges, different users can thus use the same program without having to redefine it. This enables the creation of program libraries, where users can select from a list of existing programs.

Because a Scheduler program can invoke a stored procedure or other executable that requires arguments, a means is provided to store default values for those arguments as program attributes.

See "Creating Programs" for more information about programs, and "Jobs" for an overview of jobs.

Schedules

A schedule specifies when and how many times a job is executed. Jobs can be scheduled for processing at a later time or immediately. For jobs to be executed at a later time, the user can specify a date and time when the job should start. For jobs that repeat over a period of time, an end date and time can be specified, which indicates when the schedule expires.

A schedule can also specify that a job be executed when a certain event occurs, such as a badge swipe or inventory dropping below a threshold. For more information on events, see "Events".

Similar to programs, schedules are objects that can be named and saved in the database. Users can then share named schedules. For example, the end of a business quarter may be a common time frame for many jobs. Instead having to define an end-of-quarter schedule each time a new job is defined, job creators can point to a named schedule.

Some examples of schedules you might use to control time-based jobs are:

• Run on Wednesday, December 26th, 2001 at 2pm

• Run every Monday, at 8am, starting on December 26th, 2001, and ending on January 31st, 2002

• Run on every working day

See "Creating Schedules" for more information.

Jobs

A job is a user-defined task that is scheduled to run one or more times. It is a combination of what needs to be executed (the action) and when (the schedule). Users with the right privileges can create jobs either by:

• Specifying as job attributes both the action to perform (for example, an inline PL/SQL anonymous block) and the schedule by which to perform the action (for example, every day at noon, or when a certain event occurs)

• Specifying as job attributes the names of an existing program object and an existing schedule object

The Scheduler supports the following two job types:

• Regular jobs

• Lightweight jobs

Regular Jobs

Like programs and schedules, regular jobs are schema objects. In releases before Oracle Database 11g Release 1, regular jobs were the only job type supported by the Scheduler.

A regular job offers the maximum flexibility but does entail some overhead when it is created or dropped. Regular jobs can be created with a single procedure call. The user has fine-grained control of the privileges on the job, and the job can have as its action a program or a stored procedure owned by another user.

If a relatively small number of jobs that run infrequently need to be created, then regular jobs are preferred over lightweight jobs.

Lightweight Jobs

Lightweight jobs are based on a job template from which privileges and (in some cases) job metadata is inherited. Use lightweight jobs when you need to create and drop hundreds or thousands of jobs per second or when you have a library of programs that are available to be used as job templates.

Lightweight jobs have the following characteristics:

• They are not schema objects like regular jobs.

• They have a significant improvement in create and drop time over regular jobs because they do not have the overhead of creating a schema object.

• They have a significantly lower average session creation time than regular jobs.

• They have a small footprint on disk for job metadata and runtime data.

You cannot set privileges on lightweight jobs because these jobs inherit privileges from the parent job template. Because the use of a job template is mandatory, it is not possible to create a fully self-contained lightweight job.

Job Templates

A job template is a database object that provides the necessary metadata needed for running a job (other than a schedule) and provides a privilege infrastructure that can be inherited by any lightweight job.

A job template is created based on a Scheduler program.

Job Arguments

You can specify job arguments to customize a named program object. Job arguments override the default argument values in the program object, and provide values for those program arguments that have no default value. In addition, job arguments can provide argument values to an inline action (for example, a stored procedure) that the job specifies.

A job cannot be enabled until all required program argument values are defined, either as defaults in a referenced program object, or as job arguments.

A common example of a job is one that runs a set of nightly reports. If different departments require different reports, you can create a program for this task that can be shared among different users from different departments. The program action would be to run a reports script, and the program would have one argument: the department number. Each user can then create a job that points to this program, and can specify the department number as a job argument.

See "Creating Jobs" for more information.

Events

An event is a message sent by one application or system process to another to indicate that some action or occurrence has been detected. An event is raised (sent) by one application or process, and consumed (received) by one or more applications or processes.

There are two kinds of events in the Scheduler:

• Events raised by the Scheduler

  The Scheduler can raise an event to indicate state changes that occur within the Scheduler itself. For example, the Scheduler can raise an event when a job starts, when a job completes, when a job exceeds its allotted run time, and so on. The consumer of the event is an application that takes some action in response to the event.

  For example, if due to a high system load, a job is still not started 30 minutes after the scheduled start time, the Scheduler can raise an event that causes a handler application to send a notification e-mail to the database administrator.

• Events raised by an application

  An application can raise an event to be consumed by the Scheduler. The Scheduler reacts to the event by starting a job. You can create a schedule that references an event instead of containing date, time, and recurrence information. If a job is assigned to such a schedule (an event schedule), the job runs when the event is raised. You can also create a job that has no schedule assigned and that directly references an event as the means to start the job.

  For example, when an inventory tracking system notices that the inventory has gone below a certain threshold, it can raise an event that starts an inventory replenishment job.

The Scheduler uses Oracle Streams Advanced Queuing to raise and consume events. When raising a job state change event, the Scheduler enqueues a message onto a default event queue. Applications subscribe to this queue, dequeue event messages, and take appropriate action. When raising an event to notify the Scheduler to start a job, an application enqueues a message onto a queue that was specified when setting up the job.

Chains

A chain is a grouping of programs that are linked together for a single, combined objective. An example of a chain might be "run program A and then program B, but only run program C if programs A and B complete successfully, otherwise run program D." A Scheduler job can point to a chain instead of pointing to a single program object.

Each position within a chain of interdependent programs is referred to as a step. Typically, after an initial set of chain steps has started, the execution of successive steps depends on the completion of one or more previous steps. Each step can point to one of the following:

• A program

• Another chain (a nested chain)

• An event

  A step that points to an event waits until the specified event is raised. If the event occurs, the step completes successfully.

Multiple steps in the chain can invoke the same program or nested chain.

In a sense, a chain resembles a decision tree, with many possible paths for selecting which steps run and when. A list of rules is used to decide which actions to perform at any particular stage. An example of a rule is "If step 2 fails or step 3 fails, wait an hour and then start step 4."

While a job pointing to a chain is running, the current state of all steps of the running chain can be monitored.

A typical situation where you might want to create a chain is to combine the different programs necessary for a successful financial transaction.

See "Using Chains" for more information.

How Programs, Jobs, and Schedules are Related

To define what is executed and when, you assign relationships among programs, jobs, and schedules. Figure 26-1 illustrates examples of such relationships.

Figure 26-1 Relationships Among Programs, Jobs, and Schedules

Description of "Figure 26-1 Relationships Among Programs, Jobs, and Schedules"

To understand Figure 26-1, consider a situation where tables are being analyzed. In this example, P1 would be a program to analyze a table using the DBMS_STATS package. The program has an input parameter for the table name. Two jobs, J1 and J2, both point to the same program, but each supplies a different table name. Additionally, schedule S1 could specify a run time of 2:00 a.m. every day. The end result would be that the two tables named in J1 and J2 are analyzed daily at 2:00 a.m.

Note that J4 points to no other entity, so it is self-contained with all relevant information defined in the job itself. P2, P9 and S2 illustrate that you can leave a program or schedule unassigned if you want. You could, for example, create a program that calculates a year-end inventory and temporarily leave it unassigned to any job.