DB2 Version 10.1 for Linux, UNIX, and Windows
DB2 Version 10.1 for Linux, UNIX, and Windows
Depending on the type of control that you want to maintain over your database activities, you can use workloads by themselves or both workloads and work classes (when used with work actions) to map activities to service classes.
With workloads, requests are identified and assigned to a service class based on connection attributes. Workloads are the primary method for routing work to a specific DB2® service class for execution. If you want to further refine how requests are identified, you can use work classes to classify the activities based on their type and other activity attributes. For example, you can classify READ activities, WRITE activities, and LOAD activities into different work classes and have each activity type treated differently.
If you use work classes (which are grouped into work class sets), you can use work actions to exercise control over the different types of activities. For example, you can use a work action in a work action set defined on a service superclass to map a specific type of activity to a service subclass. In a work action set defined on the database or workload, you can define a work action to apply a control known as a threshold to ensure that the same type of activity does not exceed certain conditions.
Work actions are grouped into work action sets. A single work action set can apply to activities in the database, to activities in a service superclass, or to activities in a workload. However, the same work action set cannot apply to more than one object. Work class sets and work action sets work together. That is, a work class must exist for categorizing an activity as a specific type of work before a work action can be applied to it. A work class set can be associated with more than one work action set, but a work action set can be associated with only one work class set.
Figure 1 shows an example of a DB2 workload manager implementation that uses workloads and work action sets. In this figure, assume that a request is assigned to workload WL_A based on the connection attributes of the connection that submitted the request. Workload WL_A specifies that the request is to be executed in service superclass SC_A. Assume that a work class in work class set WCS_1 matches the type of work that the request that is associated with workload WL_A is going to perform.
Now assume that an activity that does not update the catalogs (a READ activity) enters the system. The database-level work action set WAS_1 (that is associated with work class set WCS_1) contains a work action that is applied to the READ work class. The request is then mapped to service superclass SC_A (by workload WL_A). Here, the request encounters the service superclass-level work action set WAS_2, which is also associated with work class set WCS_1, and applies to activities in service superclass SC_A. This work action set contains a mapping work action, which is also applied to the READ work class so that all READ activities will be mapped to service subclass SSC_1a in service superclass SC_A.
A somewhat similar situation occurs with the request that is associated (again, based on its connection attributes) with workload WL_B. Workload WL_B maps activities to service superclass SC_B. Assume that the request is for a LOAD activity and that work class set WCS_2 contains a work class that applies to LOAD activities. Work class set WCS_2 is associated with the service superclass-level work action set WAS_3, which applies to activities in service superclass SC_B. Assume that work action set WAS_3 contains a mapping work action that is applied to the LOAD work class, so that when the LOAD activity is mapped to service superclass SC_B by workload WL_B, it will then be mapped by the work action to service subclass SSC_1b for execution.
