Rule Processing

Active rules are evaluated every time a query or other operation is executed. An active rule is an enabled rule that is associated with the currently active profile. Remember that global rules apply across all profiles. You need to be aware which global and system-defined rules are active, as well as the rules you have created. In the SMC, go to Manage > Workloads > Active Configuration and take a close look at the list under Active Rules.

To see how specific rules are applied to logged and active queries, go to Manage > Workloads > Rule Processing. This screen presents detailed information about the application of each rule to each query, including when rule processing begins and ends. Use the Filter field to narrow the scope of the entries. The Rule Examples section shows some examples of rule processing in the SMC for different types of rules.

When and how rules are processed depends on the type of rule in question; for details, see Rule Types. In general, rules are evaluated in a cycle that follows the query lifecycle. Active submit rules are evaluated first when a query starts, followed by assemble rules, compile rules, runtime rules, and finally completion rules. Any active restart rules may also be evaluated as required.

Runtime rules are evaluated every 5 seconds, assuming that the query runs longer than that time. A runtime rule may not apply the first time it is evaluated but may apply later. Other types rules are evaluated only once and either apply at that moment or not apply at all. However, note that restart rules send a query back to the assemble state, which means that certain rules will be re-evaluated for the restarted instance of the query.

Whether a rule is applied or not depends on its logic. For a given query all active rules must be evaluated but only some (or none) will be applied. For example, a rule that triggers an action when a certain user runs a query is only applied when that condition is met (along with any other related conditions).

Note: When profiles and resource pools change, these changes affect rule processing. For example, if at the end of all processing, a rule action for a query specifies a resource pool that does not exist, the rule returns an error and the query runs in the default pool. To monitor and find runtime errors like this, go to Rule Processing, enter error in the Filter field, and look for error under Type.

Setting and Matching Resource Pools in WLM Rules

A rule condition on the w.resourcePool property will not find a match unless a previous active rule in the sequence has already taken an action to set the resource pool explicitly. Until an active rule is evaluated and sets the resource pool to some other value, w.resourcePool equals null (throughout the entire rule evaluation and application process). The WLM rule definition language does not provide a way to read the current default pool name for the active profile.

For example, consider the following rule, which attempts to log a message when the resource pool is small:
if (w.resourcePool === 'small') 
             { log.info('Executed in the small pool'); }
This rule will not find a match if it is not preceded by a rule that sets the resource pool to small. For example, the following default_mapToSmall rule, which runs when the default profile is active, contains such an action:
if (w.memoryEstimate <= 1024 && w.memoryEstimateConfidence === 'High') 
             {w.resourcePool = 'small';}

If you write a rule condition on w.resourcePool, be sure to set up a prior rule that sets the pool name appropriately.