Creating a service class

You create service superclasses and service subclasses under them using the DDL statement CREATE SERVICE CLASS.

Before you begin

To create a service class, you require WLMADM or DBADM authority.

Also see the following topics for other prerequisites:

Procedure

To create a service class:

  1. Specify one or more of the following properties for the service class on the CREATE SERVICE CLASS statement:
    • Specify the name of the service class:
      Note: Once set, the name of a service class cannot be changed.
      • If you are creating a service superclass, the name must be unique among all service superclasses in the database.

        When a service superclass is created, its associated default service subclass is automatically created. Only after you have created a service superclass can you create other service subclasses under it.

      • If you are creating a service subclass, the name must be unique among all service subclasses in the service superclass. A service subclass cannot have the same name as its service superclass.
    • If you are creating a service subclass, specify the name of the parent service superclass. After a service subclass is created under a service superclass, it cannot be associated with a different service superclass.
    • Specify the buffer pool priority for the service class which affects how likely pages fetched by activities in the service class are to be swapped out. For service superclasses, the DEFAULT value internally maps to LOW. Service subclasses set to DEFAULT inherit the buffer pool priority from their parent superclasses.
    • Specify the prefetch priority. You can specify the priority with which agents in the service class can submit their prefetch requests. Depending on the value specified, the prefetch requests are routed to the high, medium, or low priority prefetch queues. The default prefetch priority is medium.
    • Specify the outbound correlator string if you want to associate the Db2® service class with an AIX® class or a Linux® class. A null value indicates no operating system workload manager association.

      If the outbound correlator is set, all threads in the Db2 service class are associated with the operating system workload manager by using the outbound correlator when the next activity begins.

      If the outbound correlator is set to NONE for a service subclass and the outbound correlator is specified for the associated service superclass, the service subclass inherits the outbound correlator specified for its service superclass.

    • Specify the activity data to collect. When activity data collection is enabled, information about an activity is sent from the coordinator member to the applicable event monitor at the end of the activity. You can write data to the event monitor that includes information about the statement that was run, its compilation environment, and any applicable input data values. You can also specify that no activity data is collected. By default, no activity data is collected.
    • Collected aggregate activity information. The aggregate activity information used for the service class only changes after the CREATE SERVICE CLASS operation is committed.
    • The type of request metrics to collect for requests submitted by a connection that is associated with the service superclass you specify. By default, basic metrics are always collected for activities associated with the workload.
    • The histogram templates that the service subclass should use as templates for its histograms. The histogram templates specified are reflected in the SYSCAT.HISTOGRAMTEMPLATEUSE view. For more information about histograms and histogram templates, see Histograms in workload management.
    • Specify whether the service class is enabled or disabled.
      • If a service class is created as enabled (the default), connections and activities can be mapped to the service class. If a service class is created as disabled, new connections and activities mapped to it are rejected.
      • If you create a service superclass as disabled, all service subclasses that you associate with this service superclass behave as though they are disabled, even though they might be displayed as being enabled when you query the SYSCAT.SERVICECLASSES view.
  2. Commit your changes.
    When you commit your changes the service class is added to the SYSCAT.SERVICECLASSES view.