12.5. Using Job Classes

A job class is a container object for the logical grouping of jobs into a larger unit. Classifying jobs in this manner offers several advantages:

• From an administrative perspective, it is easier to manage a small number of job groups than a large number of individual jobs. Certain job characteristics can be assigned at the group level and will be inherited by all jobs within the group. Certain administrative procedures will also operate at the group level, making administrative functions easier.

• Job classes can be assigned to a resource consumer group. This allows you to control resource allocation for all jobs within the group.

• Jobs can be prioritized within the job class. This gives you more control over which jobs should take precedence in case of a conflict. For example, if a conflict occurs, the JOB_PRIORITY attribute of each job will be evaluated. A job with a value of HIGH takes priority over a job with a value of LOW.

All jobs must belong to exactly one job class. Any job not explicitly assigned to a job class will belong to the DEFAULT_JOB_CLASS class, and they will inherit the characteristics of that job class. In the following sections, you will learn to create and administer job classes.

12.5.1. Job Class Parameters

Job classes have a specific set of attributes that you can set to define the characteristics of the class. These attributes will be inherited by all jobs assigned to the job class, thereby saving you the work of setting them individually on each job. The available attribute parameters are described here:

JOB_CLASS_NAME The JOB_CLASS_NAME parameter uniquely identifies the job class in the SYS schema. The name has to be unique in the SYS schema.

RESOURCE_CONSUMER_GROUP The RESOURCE_CONSUMER_GROUP parameter associates the job group with a specific consumer group. All jobs assigned to the job group will automatically be governed by this consumer group.

SERVICE The SERVICE parameter specifies the service to which the job class belongs. This means that, in a RAC environment, the jobs in this class will have affinity to the particular service specified. Therefore, they will run only on those database instances that are assigned to the specific service. If this attribute is not set, the default service will be used, meaning that the jobs have no service affinity and can be run by any instance within the cluster. If the SERVICE parameter is specified, the RESOURCE_CONSUMER_GROUP attribute cannot be set. They are mutually exclusive.

LOGGING_LEVEL The Oracle Scheduler can optionally maintain job logs of all job activities. Job logging is determined by the setting of the LOGGING_LEVEL attribute of the job class. The LOGGING_LEVEL parameter specifies how much job information is logged. There are three valid settings for this attribute:

DBMS_SCHEDULER.LOGGING_OFF No logging will be performed for any jobs in this class.

DBMS_SCHEDULER.LOGGING_RUNS Detailed information will be written for all runs of each job in the class.

DBMS_SCHEDULER.LOGGING_FULL Detailed information will be written for all runs of each job in the class, and every operation performed on any job in the class (create, enable, drop, and so on) will be logged.

Note that the valid values for this parameter are all constants defined within the DBMS_SCHEDULER package. Therefore, they must be referenced exactly as shown, with no quotes around them.

LOG_HISTORY The LOG_HISTORY parameter determines the number of days logged information should be retained. The default value is 30 days. Valid values are 1 to 999. When records have exceeded this age, the Scheduler will automatically purge them.

COMMENTS The COMMENTS parameter specifies an optional comment about the job class.

12.5.2. Creating Job Classes

Job classes can be created through the DBMS_SCHEDULER.CREATE_JOB_CLASS procedure, as shown in the following example:

SQL> begin
  2 dbms_scheduler.create_job_class(
  3 job_class_name => 'LOW_PRIORITY_CLASS',
  4 resource_consumer_group => 'LOW_GROUP',
  5 logging_level => DBMS_SCHEDULER.LOGGING_FULL,
  6 log_history => 60,
  7  comments => 'LOW PRIORITY JOB CLASS'),
  8 end;
SQL> /

PL/SQL procedure successfully completed.

In this example, a job class named LOW_PRIORITY_CLASS was created that will assign all jobs in the group to the LOW_GROUP consumer group.

12.5.3. Dropping Job Classes

Job classes can be dropped by using the DBMS_SCHEDULER.DROP_JOB_CLASS procedure. Dropping a job class that has jobs assigned to it will result in an error. However, it is allowed if the FORCE parameter is set to TRUE. In this case, the job class will be dropped and the jobs assigned to the class will be disabled. Dropping the class has no effect on any currently running instances of member jobs.

Several job classes can also be dropped at the same time by separating the names of the job classes by a comma, as shown in the following example:

SQL> begin
  2  dbms_scheduler.drop_job_class(
  3  'LOW_PRIORITY_CLASS, HIGH_PRIORITY_CLASS'),
  4  end;
SQL> /

PL/SQL procedure successfully completed.

Note that if a list of job classes is used, as in this example, there is no rollback available. For instance, if the first job class dropped but the second job class failed to drop, the procedure will return an error, but the first job class will not be restored.