When you install DB2 V9.5, a default user service class is created automatically and this default user service class is where all work submitted to the database runs (via the mapping of connections to the default workload definition that is also created at installation time). This is your starting point and any additional DB2 workloads that you create automatically point to this default service class unless a new one is explicitly identified.

This section provides recommendations for creating new DB2 service classes and pulling work out of the default service class so that it can be treated differently in terms of business priority. Each DB2 service class that you define gives you a point of control for defining resource priorities used for execution as well as the ability to do lightweight monitoring of executing work. In contrast, the more service classes you define, the more complicated your system becomes to monitor and control as a whole.

You might choose to keep the default service class in use after your implementation is complete as a place to process unmapped or unimportant work. If you choose to do this, determine what business priority should be assigned to such work and properly control the resources for the default user service class in addition to any others that you might create.

As discussed in the ["Assigning business priority to database work"] section, the DB2 service class is the best way to reflect business priority within the database. This process is often simplified by implementing a fairly straight-forward classification system where incoming work is assigned to a service class representing either a HIGH, MEDIUM, or LOW business priority or a short, medium or long expected duration.

Best Practice To implement a HIGH, MEDIUM, or LOW business priority classification system, create a DB2 service superclass and two additional service subclasses within that superclass.

Each of these service classes represents a different business priority with the default subclass for the superclass also being the default home for any unmapped work submitted to the superclass. Depending on how you wish to treat such work, you will most likely assign the default subclass to represent the LOW or MEDIUM priority class of work¹. The example implementation in this document assigns the LOW classification to the default subclass created for the superclass and the MEDIUM and HIGH classification to the two explicitly created subclasses. See "Figure 1. Recommended service class implementation" for an example.

Figure 1. Recommended service class implementation

Resources for each of these different service classes can reflect the relative priority by setting the service class attributes to values that reflect the corresponding priority (for example, the LOW business priority service subclass could get LOW prefetch priority and a low relative processor priority setting while HIGH business priority subclass could get a HIGH prefetch priority and a high relative processor priority). In general, start with having the MEDIUM business priority class reflect the original default (that is, unmodified) settings of the superclass as this is the normal setting for execution within DB2 databases.

Best Practice Do not set the service class processor priority of any service class higher than the DB2 default system service class, either directly using the processor priority attribute or indirectly through AIX Workload Manager integration.

The default behavior in this approach is such that anything mapped by a DB2 workload to the service superclass A executes in the default subclass and picks up the LOW priority settings. In order to acquire different priority settings, the incoming work needs to be mapped either to the other service subclasses using a DB2 work action set or directly to the desired service subclass. Refer to "Figure 2. Example of assigning work to different service subclasses" for an example.

Figure 2. Example of assigning work to different service subclasses

The default service subclass is assigned the lowest or medium priority because any work not recognized or not remapped within a DB2 work action set applied to the superclass is automatically assigned the lowest (or medium) priority², as long as the DB2 workload is mapped to the superclass. In general, high priority is reserved for special work rather than the ordinary run-of-the-mill work submitted to the database. You can also directly map incoming work from a workload to a subclass itself in order to assign that work that priority and by doing so, that work bypasses any DB2 work action set on the superclass. Please note that you cannot directly assign a workload to the default subclass, which should be taken into consideration when deciding which subclass will represent what business priority.

You can use this recommended approach as a template for both the monolithic approach to managing work on your database (that is, all work on the database is processed within one superclass) and for more diversified approach where different groups of work are managed using different approaches (for example, one set of work is managed using business priority and another using expected duration).

Once you have set up the DB2 service classes and workloads to reflect how you want work to be processed, validate your implementation by running known workloads and comparing the various request and activity counts for each workload and service class to ensure that things are flowing as expected. You can also use this time to test the effects of the implementation on the processing patterns. You can validate this by using either the WLM table functions to interrogate DB2 directly or the WLM statistics event monitor to collect the statistics of the different WLM objects to a table for further analysis.

Notes

¹ Note that the default attribute settings of any service subclass simply reflect the values of the superclass.

² Recall that all work on DB2 actually executes within a subclass and that any work assigned to the superclass will execute in the default subclass of that superclass.