DB2 10.5 for Linux, UNIX, and Windows

Workload management dispatcher

The workload management dispatcher manages CPU resource entitlements for workloads running within the DB2® database manager. Details about its features and functionality are provided here.

Introduction

You can use the built-in DB2 workload management dispatcher to manage DB2 workloads by configuring CPU resource entitlements without the need for third-party workload management software. The dispatcher can control DB2-specific CPU resource consumption by means of CPU shares-based settings and CPU limit settings. Soft CPU shares represent an uncapped resource allocation and can be used to allow high-priority work to consume more than its allocated share when there are unused CPU resources. Hard CPU shares and CPU limits represent a capped CPU allocation that can be used to prevent low-priority work from impacting the execution of high-priority work. CPU limits can be used to strictly control the CPU that is consumed by a particular workload in order to provide isolation for other work running on the system, whereas hard CPU shares provide the additional flexibility of allowing low-priority work to consume unused CPU resources in the absence of a high-priority workload. This scenario might occur during off-peak business hours.

The sections that follow describe the features and functionality of the workload management dispatcher in more detail. A scenarios section helps to illustrate the workload management dispatcher features and functionality with usage examples.

Features and functionality

The workload management dispatcher infrastructure operates at the instance level in the DB2 database manager. However, at the database level, you specify the CPU resource entitlements using the CPU shares and CPU limit attributes that can be placed on a service class through the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements.

As mentioned, the hard and soft CPU shares attributes have different conditions under which unused CPU resources, relinquished by a service class or a number of service classes, can be claimed by the remaining competing service classes. However, both hard and soft CPU shares attributes have the same behavior when it comes to giving back those claimed CPU resources. For example, when a service class relinquishes some or all of its full share of CPU resources, those service classes that claimed the unused CPU resources must give back the CPU resources to the service class trying to retrieve its full share when it begins to increase its demand for CPU resources. This will lead to the full restoration of the user-specified CPU resource entitlement to the retrieving service class if the demand is present. Every second, a DB2 database manager scheduler thread evaluates the CPU resource utilization by work in progress and make adjustments to ensure, over time, that the dispatcher is providing the configured CPU shares and CPU limit allocations.

The workload management dispatcher operates by limiting both the number of executing agents simultaneously dispatched to the operating system (OS) and how long each agent is allowed to execute. The number of executing agents that can be dispatched at the same time is referred to as the dispatch concurrency level which you can set using the wlm_disp_concur database manager configuration parameter.

By default, the workload management dispatcher is not enabled. To control DB2 database manager-specific CPU resource entitlements, you must first enable the workload management dispatcher. To enable the workload management dispatcher, you must set the wlm_dispatcher database manager configuration parameter to YES (by default, this configuration parameter is set to NO). For complete details about how to enable the workload management dispatcher, see: Enabling workload management dispatcher.

When the workload management dispatcher is enabled, all work running in the user and maintenance service classes within the DB2 database manager is under the control of the dispatcher. Work running in the system service class cannot be configured for CPU resource control because critical DB2 subsystems that run in this service class are given maximum priority and are not subject to workload management dispatcher control. By default, once turned on, the dispatcher can manage CPU resources only by way of CPU limit settings. To allow the dispatcher to manage CPU resources using both CPU shares and CPU limits, you must set the wlm_disp_cpu_shares database manager configuration parameter to YES.

Before or after enabling the workload management dispatcher for the first time, you will want to monitor your workloads to determine the relative CPU resources that they consume. Based on the relative priority of the workloads, this information can help in formulating your decisions concerning the creation of service classes to which the work can be assigned, the type of CPU shares (hard or soft) to assign to particular service classes, the relative quantity of CPU shares to assign to each service class, and whether to use CPU limits.

Another consideration that gives you maximum flexibility to control the behavior of the DB2 database manager is the option to set the minimum percentage of CPU resource utilization for service classes to be considered active. After setting the wlm_disp_min_util database manager configuration parameter, service classes utilizing CPU resources equal to or greater than that minimum percentage are considered to be active on the host or logical partition (LPAR) and the CPU shares of the active service classes are factored into CPU resource entitlement calculations.

Through the workload management dispatcher, you can control the allocation of CPU resources between service classes on your system via the service class CPU shares attribute. The shares attribute represents the relative entitlement of CPU time that each service class receives compared to other service classes on the system. By allocating more CPU shares to one service class and less to another, you can control the amount of CPU resources allocated to each service class and provide better quality of service to one service class over another.

After having made the decision that the earlier enabled workload management dispatcher can best manage your strained CPU resources by using CPU shares along with CPU limits, you must enable CPU shares by setting the wlm_disp_cpu_shares database manager configuration parameter to YES. The default setting for this parameter is NO. You can set and adjust CPU shares and CPU limits by using the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements.

Based on the number of CPU shares assigned to a service class, the workload management dispatcher calculates the proportion of the CPU resources that each service class is entitled to use. To determine the proportion of the CPU resources to which each service superclass is entitled, you can use the following formula to convert the number of CPU shares of a particular service superclass into a percentage of CPU resources allocated by the workload management dispatcher:

% CPU(superclass) = (Number of superclass shares / Total number of shares of all active superclasses) x 100

To determine the proportion of the CPU resources to which each service subclass is entitled, you can use the following formula to convert the number of CPU shares of a particular service subclass into a percentage of CPU resources allocated by the workload management dispatcher:

% CPU(subclass) = % CPU(superclass) x (Number of subclass shares / Total number of shares of all active subclasses in the superclass)

Note: The total number of CPU shares (both hard and soft) of all active superclasses are counted across all databases and all members on the host or LPAR.

For illustrative examples of CPU proportion calculations, see the "Usage scenarios" section.

Summary of CPU resource scheduling capabilities

The following table summarizes the features of the different CPU resource control attributes available for DB2 service classes managed by the workload management dispatcher.

Table 1. Summary of workload management dispatcher CPU resource scheduling capabilities
CPU resource control attribute	Usage of idle CPU resources in the same context	CPU resource entitlement limits are relative to other active service classes in the same context	CPU resource entitlement limits are fixed based on overall system CPU capacity	Control of CPU consumption at high CPU resource utilization	Control of CPU consumption at low CPU resource utilization	Usage notes
Soft shares	Y	Y	N	Y	N	Ideal for high-priority work to exploit any spare CPU resources available on the host or LPAR to maximize workload progress
Hard shares	N	Y	N	Y	Y	Ideal for ensuring work does not interfere with higher priority work which might be running on the host or LPAR in various amounts and intensity
CPU limits	N	N	Y	Y	Y	Ideal for sandboxing and enforcing consistent fixed CPU resource allocations between service classes, or limiting service class CPU resource consumption regardless of other work on the host or LPAR

Effects of work outside of workload management dispatcher control

A workload management dispatcher exists for each DB2 instance. It can only directly detect and manage DB2 work within its own instance. Any other work running on the same host or LPAR is not under the direct control of the dispatcher. The random nature of the CPU resource demands of work running outside of the DB2 database manager means that while the CPU limits and the relative shares of CPU resources among work executing within DB2 can be enforced, at any given instant of time, the work managed by the dispatcher still needs to compete with work running outside its own DB2 instance and outside the dispatcher's direct control. Work that is neither detected nor managed by the workload management dispatcher includes the following:

Work performed by applications or middleware products that perform a portion of their work outside of the DB2 database manager
Work performed by entities executing in the DB2 system service class
Work performed by other DB2 instances
Non-DB2 work performed in fenced mode processes such as fenced stored procedures
Non-DB2 work performed in trusted routines. Trusted procedures and user-defined functions (UDFs) are accounted for in dispatcher CPU resource scheduling, but the dispatcher is not able to limit CPU utilization when a trusted routine executes in user code for long periods of time.
Figure 1. Example system diagram

Let's consider that you have a host or LPAR that runs only the DB2 database manager. You have created a database with service classes A and B and assigned a 50% share of the CPU resources to each service class. Assuming the overall host or LPAR makes full use of the CPU resources at all times, your measurements of total CPU utilization (%) over time looks similar to that shown in Figure 2 panel A.

Figure 2. Total CPU utilization percentage

Now, let's consider what happens when fenced mode processes (FMPs) are executed on your host or LPAR. These processes are not under the control of the workload management dispatcher, so the amount of CPU resources they use varies randomly. However, out of the remaining CPU resources that the dispatcher can manage, service classes A and B each continue to get an equal 50% split of the leftover CPU resources, as shown in panel B.

Interactions between dispatcher and other service class settings

The following table summarizes how the workload management dispatcher settings on a service class (hard and soft CPU shares, and CPU limit) interact with other settings on the same service class.

Table 2. Interactions between dispatcher and other service class settings
Dispatcher service class setting	Other service class setting	Interaction
Hard and soft CPU shares, and CPU limit	Outbound correlator (OS WLM integration)	Hard and soft CPU shares, CPU limit, and OS WLM can all be active at the same time.
Hard and soft CPU shares, and CPU limit	Buffer pool priority	Hard and soft CPU shares, CPU limit, and buffer pool priority can all be active at the same time.
Hard and soft CPU shares, and CPU limit	Prefetch priority	Hard and soft CPU shares, CPU limit, and prefetch priority can all be active at the same time.

Interaction between dispatcher settings and thresholds with a REMAP action

Some workload management thresholds support a REMAP ACTIVITY action to move executing work from one service subclass to another within the same service superclass. When work moves to a service subclass with a different CPU share or CPU limit than the service subclass it moved from, the CPU share and CPU limit settings of the service subclass to which the work moves are applied.

Comparison between workload management dispatcher and workload management concurrency thresholds

Although you can control workload scheduling and resource consumption using both the workload management dispatcher and concurrency thresholds, knowing the differences in their degree of workload control and benefits will help you to decide when to apply one or both in your environment. The following table compares their abilities to control CPU resources.

Table 3. Comparison of CPU resource control abilities between workload management dispatcher and workload management concurrency thresholds
Workload management dispatcher	DB2 workload management concurrency thresholds
You can directly control CPU allocations within the DB2 database manager after an activity begins consuming CPU resources.	You can indirectly control both the consumption of CPU and other resources, such as memory, by limiting the number of connections or activities that are allowed to execute at the same time.
You can configure relative allocations of soft and hard shares of CPU resources to service classes, in addition to absolute limits of CPU consumption by a single service class.	You can impose an absolute limit on the concurrency of executing activities or open connections for a service class, but you cannot specify any kind of relative CPU allocations.

Comparison between workload management dispatcher and OS WLMs (AIX WLM and Linux WLM)

The workload management dispatcher can be used together with an OS WLM (AIX® WLM or Linux WLM) in certain situations to provide even greater control. The following are some examples of circumstances in which both the workload management dispatcher and an OS WLM can work together:

OS WLMs often have OS-level monitoring that complements the workload management dispatcher monitoring capabilities.
OS WLMs can manage all applications on the system, including the DBMS. The workload management dispatcher can provide DB2-specific dispatching, while the OS WLM manages all the other applications on the system.
Do not attempt to control CPU resource allocations to individual service classes with both the OS WLM and the workload management dispatcher at the same time. You can integrate an OS WLM at the service class level for monitoring purposes when the workload management dispatcher is enabled. You can also integrate an OS WLM to control external applications, or the overall CPU resources allocated to a DB2 instance, or both.

Table 4. Comparison of abilities between workload management dispatcher and OS WLM
Workload management dispatcher	OS WLM
A single solution that works across all platforms.	An OS WLM is specific to each OS. Each has its own user interface and its own limitations.
You can control CPU allocations within the DB2 database manager without the need for any OS-specific integration and/or set up - a DBA can manage these settings without requiring root access to the system.	An OS WLM often requires root privilege for configuration.
You can leverage database-specific knowledge when making CPU resource scheduling decisions that would otherwise not be possible with OS-level facilities.	An OS WLM treats the DB2 database manager as just another application and, therefore, cannot use database-specific knowledge to make CPU resource scheduling decisions.
In multiple member environments, all members can be configured with one command. However, the result is that you cannot have a different configuration at each member.	In multiple member environments, an OS WLM must be configured at every member. You can have a different configuration at each member.
Controls the use of CPU resources by only DB2 work running in the user and maintenance service classes within the scope of a single DB2 instance. The dispatcher cannot control the use of CPU resources by applications executing external to the DB2 instance.	An OS WLM can fully control CPU resources on the entire system.
CPU resource control is accomplished through both soft and hard CPU shares.	OS WLM solutions on AIX and Linux do not currently provide an equivalent of the DB2 hard CPU shares.

Usage scenarios

Scenario 1: CPU entitlement calculations

Figure 3 shows the data server configured as illustrated. For illustration purposes to help describe the basic concepts, assume that there is negligible work running in the default user, maintenance, and system service classes. At the start of the scenario, consider that there is enough work executing in the user service superclasses A, B, and C to use the full CPU resource entitlements for those service classes. For the following scenario, there is only one DB2 instance with one database and only one logical member on this host or LPAR.

Figure 3. Data server configuration

As shown in Figure 3, the CPU entitlement percentage for each of the service superclasses is calculated as follows:

Service superclass A has 60%
```
(6000 / (6000 + 3000 + 1000)) x 100
```
Service superclass B has 30%
```
(3000 / (6000 + 3000 + 1000)) x 100
```
Service superclass C has 10%
```
(1000 / (6000 + 3000 + 1000)) x 100
```

CPU shares can be assigned at both the service superclass and service subclass levels. If you do not specify CPU shares when creating a service superclass or service subclass, the DB2 database manager assigns a default of 1000 hard CPU shares to such service classes. At the superclass level, the CPU shares value represents how the system CPU resources are divided among DB2 service superclasses. At the subclass level, the CPU shares value represents the division of the CPU resources available to a particular superclass among its active subclasses.

Scenario 2: Workload management dispatcher operates at instance level; service classes operate at database level

The workload management dispatcher operates at the instance level, but the configurations (CPU shares and CPU limits) that the dispatcher uses to allocate CPU resources are placed on individual service superclasses and service subclasses within individual databases. When multiple databases exist within the same instance, the sum of the CPU share values within service superclasses on each database determines the relative allocation of the CPU resources that each database receives. For example, there are two databases in the same instance, database A and database B, each database has two service superclasses (SC1 and SC2), as shown in Figure 4 panel A.

Figure 4. CPU shares allocations to service classes for two databases in one instance

In this example scenario, we want a 70/30 percentage split of CPU resources in database A which is configured using soft CPU shares of 7000 and 3000 for SC1 and SC2, respectively, as shown in panel B. In database B, we want a 60/40 percentage split of CPU resources for SC1 and SC2, respectively, as shown in panel C.

Before deciding on how this 60/40 percentage split translates into CPU shares in the two service superclasses for database B, we must decide what are the required relative CPU resource entitlements between databases A and B. The work running in database B is much more important than that running in database A. Therefore, we want database B to have a CPU entitlement of 80% and database A to have 20%.

The sum of the CPU shares on database A is 10,000. These 10,000 CPU shares represent 20% of the total CPU shares across the two databases, we require 50,000 CPU shares in total to represent 100% of the total CPU resources. Therefore, database B must be assigned 80% of those 50,000 CPU shares, resulting in 40,000 CPU shares. To obtain the 60/40 percentage split between the two superclasses of database B, service superclass SC1 receives 60% of the 40,000 total CPU shares assigned in database B, resulting in 24,000 CPU shares. Service superclass SC2 receives 40% of the 40,000 total CPU shares assigned in database B, resulting in 16,000 CPU shares.

The pie chart shows the CPU shares assignments that achieved the percentage CPU resource allocations that we wanted.

Scenario 3: Favor one workload over another at high CPU utilization and protect favored workload at low CPU utilization

In this example usage scenario, the aim is to manage the quality of service for multiple workloads while simultaneously maximizing the CPU utilization on the system. However, in addition to experiencing contention for the CPU resources, the workloads in this scenario experience contention for other resources. Allocating unused CPU resources to some workloads when competing workloads, not consuming their full CPU entitlement, are still present, can cause a degradation in performance due to CPU cache contention, I/O contention, or other secondary effects.

In this scenario, there is a need to protect the favored workload from unfavored workloads, despite the possibility that the CPU resources are not fully utilized. The under-utilized CPU resources can result when unfavored workloads are limited and the favored workload is active, but not using its full CPU entitlement. We can accomplish protecting the favored workload by assigning hard CPU shares on the unfavored workloads and assigning soft CPU shares on the favored workload.

Again, let's use two workloads: 'Favored' and 'Other'. The 'Favored' workload is to have 70% of the CPU resources when running at the same time as the 'Other' workload and 100% when the 'Other' workload is not present. The 'Other' workload is to have 30% of the CPU resources when running at the same time as the 'Favored' workload and 100% when the 'Favored' workload is not present. This is similar to Scenario 3, except that the overall CPU utilization drops below 100% on occasion.

The following steps show how to configure DB2 workload management to achieve the goals listed previously:

Create the 'Favored' and 'Other' service superclasses and assign CPU shares so that the 70/30 CPU entitlement proportion is met. CPU shares can be specified as 7 and 3, 14 and 6, or any other combination that achieves the 70%/30% CPU entitlement ratio. In the following example, 7000 soft CPU shares are assigned to the 'Favored' service class and 3000 hard CPU shares are assigned to the 'Other' service class:
```
create service class favored soft cpu shares 7000
create service class other hard cpu shares 3000
```
Create the 'Favored' and 'Other' workloads as shown in the following example:
```
create workload favored appl_name('favoredapp') service class favored
create workload other appl_name('otherapp') service class other
```
As a result, the system looks like the following:
Figure 5. Data server configuration

For simplicity, assume only a negligible amount of work is running in the service classes other than 'Favored' and 'Other'.
Measure whether the desired CPU share goals are being achieved. The system can be in one of several states in terms of its workload:
1. 100% CPU utilization
  1. Work is executing in both the 'Favored' workload and the 'Other' workload
    The measured CPU utilization is 70% for the 'Favored' service class and 30% for the 'Other' service class.
  2. Work is executing in only the 'Favored' workload
    The measured CPU utilization is 100% for the 'Favored' service class and 0% for the 'Other' service class.
  3. Work is executing in only the 'Other' workload
    The measured CPU utilization is 0% for the 'Favored' service class and 100% for the 'Other' service class.
2. A service class uses less than its CPU entitlement
  1. Work is executing in both the 'Favored' workload and the 'Other' workload. The 'Favored' workload is using 50% instead of the full 70% that comes from its CPU entitlement.
    The measured CPU utilization of the 'Favored' workload is 50%. The 'Other' workload continues to use 30% because its CPU shares are hard. The total CPU utilization is 80%.
  2. Work is executing in both the 'Favored' workload and the 'Other' workload. The 'Other' workload is using 10% instead of the full 30% that comes from its CPU entitlement.
    Due to its CPU shares being soft, the measured CPU utilization of the 'Favored' service class increases from 70% to 90%, claiming the unused 20% relinquished by the 'Other' service class. The CPU utilization of the 'Other' service class is 10%. The total CPU utilization is 100%.
  3. Work is executing in only the 'Favored' workload and it uses all of its CPU entitlement
    Due to the absence of work running in the 'Other' service class, the 'Favored' service class can use both its own CPU entitlement of 70% and the unused 30% of CPU resources relinquished by the 'Other' service class. The total CPU utilization is 100%.
  4. Work is executing in only the 'Other' workload and it uses all of its CPU entitlement
    Due to the absence of work running in the 'Favored' service class, the 'Other' service class can use both its own CPU entitlement of 30% and the unused 70% of CPU resources relinquished by the 'Favored' service class. The total CPU utilization is 100%.

Scenario 4: Create a sandbox to achieve consistency, even at the expense of some CPU resources becoming idle

In this example usage scenario, a favored workload never consumes more than its fixed proportion of CPU resources, regardless of the availability of unused CPU resources.

Let's use two workloads: 'Favored' and 'Other'. The 'Favored' workload is to have a maximum of 70% of the CPU resources at any time, regardless of the availability of unused CPU resources. The 'Other' workload is to have a maximum of 30% of the CPU resources at any time, regardless of the availability of unused CPU resources.

The following steps show how to configure DB2 workload management to achieve the goals listed previously:

Create the 'Favored' and 'Other' service classes and assign each with a CPU limit so that the maximum 70% and 30% of CPU resources is enforced for the 'Favored' and the 'Other' workloads, respectively. In the following example, CPU limits must be specified as a number between 1 and 100, which represents the maximum percentage of CPU utilization for that service class:
```
create service class favored cpu limit 7000
create service class other cpu limit 3000
```
Create the 'Favored' and 'Other' workloads as shown in the following example:
```
create workload favored appl_name('favoredapp') service class favored
create workload other appl_name('otherapp') service class other
```
As a result, the system looks like that in Figure 5.
For simplicity, assume only a negligible amount of work is running in the service classes other than 'Favored' and 'Other'.
Measure whether the desired CPU limits are successfully being enforced. The system can be in one of several states in terms of its workload:
1. 100% CPU utilization
  1. Work is executing in both the 'Favored' workload and the 'Other' workload
    The measured CPU utilization is 70% for the 'Favored' service class and 30% for the 'Other' service class.
2. One or more service classes uses less than its CPU limit
  1. Work is executing in both the 'Favored' workload and the 'Other' workload. The 'Favored' workload is using 50% instead of the full 70% that comes from its CPU limit entitlement.
    The measured CPU utilization of the 'Favored' workload is 50%. The 'Other' workload continues to use 30% because that is the maximum CPU limit entitlement. The total CPU utilization is 80%.
  2. Work is executing in both the 'Favored' workload and the 'Other' workload. The 'Other' workload is using 10% instead of the full 30% that comes from its CPU limit entitlement.
    Due to its CPU limit that stipulates a maximum of 70% CPU utilization, the measured CPU utilization of the 'Favored' service class remains at 70%. The unused 20% of CPU resources relinquished by the 'Other' service class remains unclaimed. The CPU utilization of the 'Other' service class is 10%. The total CPU utilization is 80%.
  3. Work is executing in only the 'Favored' workload and it is using the maximum amount of CPU resources as stipulated by its CPU limit
    Due to its CPU limit that stipulates a maximum of 70% CPU utilization, the measured CPU utilization of the 'Favored' service class remains at 70%. The unused 30% of CPU resources relinquished by the 'Other' service class remains unclaimed. The CPU utilization of the 'Other' service class is 0%. The total CPU utilization is 70%.
  4. Work is executing in only the 'Other' workload and it is using the maximum amount of CPU resources as stipulated by its CPU limit
    Due to its CPU limit that stipulates a maximum of 30% CPU utilization, the measured CPU utilization of the 'Other' service class remains at 30%. The unused 70% of CPU resources relinquished by the 'Favored' service class remains unclaimed. The CPU utilization of the 'Favored' service class is 0%. The total CPU utilization is 30%.

Scenario 5: Needing to divide workloads by user and still favor one type of work over another for a given user

In the preceding scenarios, service classes were used to control the allocation of CPU resources between different workloads based on business priorities. In some cases, it might be desirable to both control the share of resources among workloads based on business priorities, and prioritize short-running work over long-running work to improve overall throughput or response times.

In this example usage scenario, a CEO and all of the one thousand other employees access a database through one application named mybizapp. Our aim is to give the CEO alone a full 10% share of the CPU resources and the remaining 90% of the CPU resources is used by the one thousand other users that access the database. To accomplish this goal, create a service superclass for the CEO (ceo_sc). Then, define a workload to map the CEO to her service superclass, as shown in the following examples:

create service class ceo_sc soft cpu shares 1000
create workload ceo_wl
  applname('mybizapp')
  session_user('ceo')
  service class ceo_sc

Create a service superclass for all of the other users (mybizapp_sc). Then, define a workload (mybizapp_wl) to map all of the other users of the mybizapp application to the newly created service superclass mybizapp_sc, as shown in the following example:

create service class mybizapp_sc hard cpu shares 9000
create workload mybizapp_wl
  applname('mybizapp')
  service class mybizapp_sc

Within the workload of the mybizapp application, there are both high-cost and low-cost queries. The business organization has determined that low-cost queries, costing less than 10,000 timerons, are generally higher in priority than high-cost queries, costing more than 10,000 timerons. Therefore, low-cost queries are to be given a greater share of the CPU resources than high-cost queries, specifically by a 2:1 ratio. To accomplish this goal, create two service subclasses (lowcost_ssc and highcost_ssc) within the mybizapp_sc service superclass and assign soft CPU shares in a ratio of 2:1, as shown in the following example:

create service class lowcost_ssc under mybizapp_sc soft cpu shares 2000
create service class highcost_ssc under mybizapp_sc soft cpu shares 1000

The 2:1 ratio of soft CPU shares determines how much of the 90% of the CPU resources assigned to the mybizapp_sc service superclass is allocated to low-cost queries and how much is allocated to high-cost queries.

Create a work class set (splitbycost_wcs) and work action set (mybizapp_was) to route low-cost queries to the lowcost_ssc service subclass and high-cost queries to the highcost_ssc service subclass, as shown in the following examples:

create work class set splitbycost_wcs
 (work class lowcost_wc work type dml for timeroncost from 0 to 10000,
 work class highcost_wc work type dml for timeroncost from 10001)

create work action set mybizapp_was for service class mybizapp_sc
 using work class set splitbycost_wcs
 (work action maplowcost_wa on work class lowcost_wc map activity
 to lowcost_ssc, work action maphighcost_wa on work class highcost_wc
 map activity to highcost_ssc)

When work is executing in each of the service classes and consuming its full CPU resource entitlement, the previous configurations result in a division of the CPU resources, as shown in the following figure:

Figure 6. CPU resource entitlements

The ceo_sc service superclass has 1000 CPU shares out of 10,000, resulting in a CPU resource entitlement of 10%. The mybizapp_sc service superclass has 9000 CPU shares out of 10,000, resulting in a CPU resource entitlement of 90%. Within the 90% of the mybizapp_sc service superclass CPU resource entitlement, its lowcost_ssc service subclass has 2 shares out of 3, resulting in a CPU resource entitlement of 66.7% of the CPU resources of its service superclass, or 60% of the total CPU resources. The highcost_ssc service subclass has 1 share out of 3, resulting in a CPU resource entitlement of 33.3% of the CPU resources of its superclass, or 30% of the total CPU resources.