DB2 WLM can prioritize activities based on the accessed data

Using DB2® WLM, you can now prioritize an activity based on the data that the activity accesses, either before the activity executes (predictively) or while the activity is executing (reactively).

To prioritize an activity, you use a combination of a data tag, which is a numeric identifier applied to a table space or storage group, and WLM controls. For example, if you have a table space IMPORTANT_TS containing critical data that has a data tag assigned to it, you could map any query that reads data from a table in this table space to a service class that is allocated a higher percentage of overall CPU cycles on the system.

You can assign a data tag directly to a table space or assign the data tag to the storage group for the table space and have the table space inherit the data tag from the storage group. Storage groups are groups of storage paths with similar characteristics. Using a multi-temperature data storage approach, you can create storage groups that map to different classes of storage in your system. You can assign automatic storage table spaces to these storage groups, based on which table spaces have hot, warm, or cold data. Frequently accessed (hot) data is stored on fast storage, infrequently accessed (warm) data is stored on slower storage, and rarely accessed (cold) data is stored on slow, less-expensive storage. As hot data cools down and is accessed less frequently, you can move it to slower storage. You can dynamically reassign a table space to a different storage group by using the ALTER TABLESPACE statement, specifying the USING STOGROUP option.

Predictive prioritization using work class and work action sets uses an estimated data tag list that is obtained for an activity at compile time, similar to cost and cardinality estimates. The estimated data tag list contains the data tags for all table spaces that the compiler believes will be accessed during execution of the activity. You can define work class sets to identify activities that have a particular data tag in their estimated data tag lists. You can then define a work action to map any activities matching a work class set to a specific service class before they begin to execute.

Reactive prioritization using the new DATATAGINSC threshold maps an activity to a different service class at run time when the activity accesses data that is assigned a particular data tag. For example, you can specify that an activity will be mapped to a different service class when it reads data from a table space with data tag value of 3. Reactive prioritization is useful if the compiler cannot accurately estimate the list of data tags for the activity. An example of such a case is a query against a range-partitioned table that uses parameter markers. The compiler cannot necessarily determine what table ranges are accessed in advance.