DB2 Version 10.1 for Linux, UNIX, and Windows

Activity-to-service class mapping

All database connections are assigned to a workload at the beginning of the first unit of work. When a workload occurrence is started, all activities running under that workload occurrence are mapped to service classes based on the service class name specified in the workload definition.

The data server assigns a connection to a workload definition if the connection meets the criteria defined for that workload definition. For example, you can set up a workload management configuration so that all connections from application A belong to the workload definition Alpha, while all connections from application B belong to the workload definition Beta.

If the workload occurrence is assigned to a service superclass, activities submitted for that workload occurrence can be reassigned to a user-defined service subclass in that service superclass using a work action set.

You can use the workload to map activities from a connection to a service superclass by specifying the SERVICE CLASS keyword of the CREATE WORKLOAD statement. Assuming that no work class or work action applies to the activity, the activity is run in the default service subclass of the service superclass. You can also use a workload to map activities from a connection to a service subclass in the service superclass by specifying the UNDER keyword for the SERVICE CLASS keyword of the CREATE WORKLOAD statement. In this situation, the connection still belongs to the service superclass, but all activities issued from that connection are automatically mapped to the service subclass specified in the workload definition.

After an activity has been mapped to a service subclass and has begun executing, it stays in that service subclass, unless you remap it to another service subclass (with a threshold). Remapping is the process by which you can change the resource assignments for an activity through a different activity-to-service subclass mapping. Both the source and the target service subclasses must exist under the same superclass. After the activity is remapped, it continues to execute in the new service subclass.

The following figure shows the relationship between connections, workloads, and service superclasses. Connections that meet the definition of workload A are mapped to service superclass 1; connections that meet the definition of workloads B or C are mapped to service superclass 2; connections that meet the definition of workload D are mapped to the SYSDEFAULTUSERCLASS service superclass.

Figure 1. Mapping of database connections to a service superclass

Further differentiating between activities

If you have a more complex DB2® workload manager configuration, you might want to handle activities differently based on either the activity type or some other activity attribute. For example, you might want to do one of the following actions:

Put DML in a different service subclass than DDL.
Put all read-type queries with an estimated cost of less than 100 timerons in a different service subclass than all the other read-type queries.

In a more complex configuration you can set up the workload to map activities from the connection to the service superclass. Then, using work actions (contained in a work action set that is applied to the service superclass), you can remap activities, based on their type or attribute, to specific service subclasses in a service superclass.

Specifically, you could apply a work action set that contains a MAP ACTIVITY work action to the service superclass. All activities that are both mapped to the service superclass and match a work class to which a MAP ACTIVITY work action is associated are mapped to the service subclass specified by the work action.

If a workload definition associates itself with a service subclass, any activities that are submitted through that workload are not affected by a work action set that is assigned to the parent service superclass.

An activity can be mapped to one service subclass in a service superclass by a workload.
A work action that maps the activity to a different service subclass in the same service superclass also applies to the activity.

If an activity is not mapped to a service subclass through a workload or a work action, the activity is mapped to the default subclass (SYSDEFAULTSUBCLASS) of the service superclass for that activity.

When database activities have been mapped to their respective service superclasses and service subclasses, you can implement controls on all the activities in a particular service class. Statistics are available at the service-class level that you can use to monitor database activities in that service class.

The following figure shows requests to the database being mapped to a service superclass or service subclass through workloads. For information on how work actions are used to map activities to a service subclass, see Work actions and work action sets

Figure 2. Database connections being mapped to a service superclass

Database requests being mapped to a service superclass

Connections that do not map to a user-defined workload definition are mapped to the default user workload definition, SYSDEFAULTUSERWORKLOAD. By default, connections from the default workload definition (SYSDEFAULTUSERWORKLOAD) are mapped to the SYSDEFAULTUSERCLASS service superclass, which is the default service superclass for user requests. You can alter the SYSDEFAULTUSERWORKLOAD workload so that it maps to a different service class. Internal DB2 maintenance connections are mapped to the SYSDEFAULTMAINTENANCECLASS, which is the default service superclass for maintenance requests. Internal system entities and connections are mapped to SYSDEFAULTSYSTEMCLASS, which is the default service superclass for internal DB2 connections and threads that perform system-level tasks.