Work actions and work action sets
A work action, when used in conjunction with a work class, can be used to help control specific types of activities. For example, you can apply different work actions to LOAD activities so that they are processed differently than DML. Work actions are grouped into work action sets.
Work actions
- A user-supplied work action name, which must be unique in the work action set.
- The work class identifier the work action is to be applied to. You can define more than one work action for a work class, but each work action must perform a different action on that work class.
- The action that is to be applied to the database activity that
matches the work class. The valid action type for a work action depends
on whether the work action set that the work action belongs to is
applied to a database, a workload, or a service superclass. When a
work action set is applied to a database, all work entering the database
is evaluated by the work action set. When a work action set is applied
to a workload, all work submitted through workload occurrences associated
with that workload are evaluated by that work action set. When a work
action set is applied to a service superclass, all work submitted
for execution directly to the service superclass is evaluated by that
work action set; that is, workload definitions that specifically name
the service superclass as their target service class will have their
submitted work evaluated by the work action set defined on the service
superclass. For example:
- A work action set that is applied to a database or a workload can contain threshold work actions. If an activity gets assigned to a work class that has a threshold work action defined for it, the threshold is applied to that activity.
- A work action set that is applied to a service superclass can contain a work action that maps the activity to a service subclass in the service superclass. If an activity corresponds to a specific work class in a work class set, and the work action set has a mapping work action that is defined for that work class, that activity is mapped to the service subclass specified by the work action.
For a list of the supported actions, see Work actions and the work action set domain.
- An object that is the target of the specified action. Depending on the action, the object can be a service subclass that the activity is mapped to, a threshold that specifies which threshold to apply to the activity, or null if the action is to prevent execution, one of the collect actions, or count activity.
- The template describing the histogram that collects statistical information about the number of milliseconds that activities associated with the work class to which this work action is assigned required to run during a specific interval. This information is only collected when the work action type is COLLECT AGGREGATE ACTIVITY DATA (either BASE or EXTENDED). For more information on histograms and histogram templates, see Histograms in workload management.
- Whether or not the work action is enabled.
- An automatically generated identifier that identifies the work action.
You can create a work action by using either the WORK ACTION keyword in the CREATE WORK ACTION SET statement or the ADD keyword in the ALTER WORK ACTION SET statement. You can alter a work action by using the ALTER keyword in the ALTER WORK ACTION SET statement. You can remove a work action from a work action set by using the DROP keyword in the ALTER WORK ACTION SET statement, or by dropping the entire work action set.
You can view your work actions by querying the SYSCAT.WORKACTIONS view.
Work action sets
- A work action set name that is unique in a database.
- The name of the work class set containing one or more work classes
that the group of actions is to apply to.
Because the definitions of the work class sets are separate from the work action sets defined for them, you can define more than one work action set for a work class set.
- The type of object that the work action set is associated with (database, service superclass, or workload).
- The name of the service superclass that the actions and work class set apply to (for work action sets associated with a service superclass).
- Whether or not the work action set is enabled.
- User comments.
- One or more work actions (a work action set does not have to contain any work actions).
- An automatically generated ID that uniquely identifies the work action set.
You can create a work action set using the CREATE WORK ACTION SET statement, alter a work action set using the ALTER WORK ACTION SET statement, and drop a work action set using the DROP WORK ACTION SET statement.
You can view your work action sets by querying the SYSCAT.WORKACTIONSETS view.
When you create a work action set, you must specify the object that the work action set is to be applied to. The valid object types are the database, a workload, or a service superclass. You must also specify which work class set the work action set is to work with. This permits you to use the work classes in the work class set to identify the types of activities that you want to apply the work actions to.
- If you set up a workload to map its database activities directly to a service subclass, the work action set associated with that service superclass is never used for the activities issued by that workload. In other words, if a workload maps activities directly to a service subclass, the work action set is bypassed. None of the work actions in the work action set will be applied to the activities that are mapped directly to the service subclass.
- Any activity, not mapped to a service subclass by a work action within the work action set on the superclass, executes in the SYSDEFAULTSUBCLASS of the service superclass.
- All work submitted by a workload associated with the superclass that is not recognized as an activity, such as a PREPARE request or RUNSTATS, executes in the SYSDEFAULTSUBCLASS of the service superclass since the work action set does not affect them.