Resource assignment with service classes

A service class defines an execution environment in which work can run. This execution environment allocates available resources and can include thresholds that determine how work is permitted to run.

All work runs in a service class and you use workloads to assign work to service superclasses, or you assign work to service subclasses in a service superclass by using workloads, the REMAP ACTIVITY threshold action, or the MAP ACTIVITY work action. When you define a workload, you indicate the service class where work associated with that workload runs. By default, a default user workload also exists (SYSDEFAULTUSERWORKLOAD) that maps work to the default user service class (SYSDEFAULTUSERCLASS), so that any work not explicitly mapped to a user defined service class using a user defined workload will run in the default user service class.

Without service classes, requests cannot be organized into recognizable, logical groupings, as is shown in the following figure.

Work on the data server is not organized or grouped and performed in any order and without preference — Figure 1. Unorganized work

You can create different service superclasses to provide the execution environment for different types of work, then assign the applicable requests to the service superclasses. Assume that you have applications from two separate lines of business, finance and inventory. Each line of business would have its own applications to fulfill its responsibilities to the organization. You can organize the requests into categories that make sense for your workload management objectives. In the following figure, different service superclasses are assigned to different lines of business.

Work is organized by service classes and performed according to business priority — Figure 2. Work organized by service classes

In the previous figure, the activities in both service superclasses are further subdivided. The service class provides a two-tier hierarchy: a service superclass and service subclasses underneath. This hierarchy permits for a more complex division of execution environment and better emulates a real-world model. Unless specified otherwise, service subclasses inherit characteristics from the service superclass. Use the service subclasses to further subdivide work in the service superclass.

Prioritization and resource control

When you create or alter a service class object, you can define a number of resource controls:

Table 1. Resource control afforded by service classes
Control	Description
Soft resource shares	Use this control to compute a soft resource entitlement for the service class. The soft entitlement is the maximum resources the service class is allowed when resources are under competition. A soft entitlement may be exceeded when there is spare resource capacity (i.e. other service classes are not using their full resource entitlement).
Hard resource shares	Use this control to compute a hard resource entitlement for the service class. The hard entitlement is the maximum amount of resources the service class is allowed.
Minimum resource share	Use this control to indicate a percentage of the entitled resources that are held in reserve for the service class (i.e. minimum resource allocation).
CPU limits	Use this control to limit the amount of CPU that work running in a service class is allowed to use.
CPU shares	Use this to determine the distribution of CPU resources between service classes. This is based on the amount of CPU shares given to all service classes and the amount of work running there.
Prefetch priority	Use this control to assign a priority to the prefetch requests, which affects the order in which they are addressed by the data server.
Buffer pool priority	Use this control to assign a buffer pool priority to service classes which affects how likely pages fetched by activities in a service class are to be swapped out.
Outbound correlator	Use this control to permit a workload to have some of its resources controlled by an external workload manager such as AIX® Workload Manager or Linux® workload management. The agent passes the outbound correlator to the external workload manager, which uses it to map the workload to one of the external workload manager's resource groups. Note: This control cannot be set when agent priority is in use. When Db2® workload management is used in conjunction with an external workload manager, additional controls are available. With AIX Workload Manager, you can control the amount of processor resource allocated to each service class by setting a minimum, maximum, or relative share of processor resource for each service class. With Linux workload management, you can control the amount of CPU resource by setting shares for each service class relative to the Linux default class.

Note: Resource shares are only applied in an environment where WLM Admission Control is enabled. WLM Admission Control is enabled when the database manager configuration parameter wlm_admission_ctrl is set to YES.

Service subclasses

Although the service superclass is the highest tier for work, activities run only in service subclasses. Each service superclass has a default service subclass defined to run activities that you do not assign to an explicitly defined subclass. This default subclass is created when the service superclass is created. You can create additional subclasses in a service class as you require them to further isolate work. Except for histograms and the COLLECT ACTIVITY DATA, COLLECT AGGREGATE ACTIVITY DATA and COLLECT AGGREGATE REQUEST DATA options, a service subclass inherits the attributes of its service superclass, unless otherwise specified. The resources of the superclass are shared by all subclasses in it.

You can define only a single level of subclasses (that is, you cannot define a subclass under another subclass, only under a service superclass).

The following figure is an example of a custom Db2 workload management configuration using workloads and service classes:

As user requests enter the data server, they are identified as belonging to a given workload and assigned to a service superclass or subclass. There are also system requests (for example, prefetches) that run under a special default system service class (SYSDEFAULTSYSTEMCLASS) and maintenance requests that are driven by Db2 (such as an automatic RUNSTATS from the health monitor) that run under a default maintenance service class (SYSDEFAULTMAINTENANCECLASS).

You can view your service classes by querying the SYSCAT.SERVICECLASSES catalog view.