Product DocumentationAppearance
Rule Types
The following table defines the types of rules that you can create. You can apply a rule at certain points in the life cycle of a query by specifying a type that maps to the current state of the query. Rules are applied as the query enters the state defined by the rule type. See also How Queries Are Executed.
| Rule Type | Description |
|---|---|
| Submit | Evaluated when the query is first registered by the front-end database. |
| Assemble | Evaluated when the query is building the artifacts required for query compilation, before it is submitted to a resource pool. A variety of actions can be taken at this stage, including imposing limits on execution time and memory, setting query priority, or selecting a resource pool. |
| Compile | Evaluated during the pre-execution phase for a query, when a resource pool has been selected. The same set of actions that you can apply for Assemble rules are available, along with one additional action: the ability to move the query to a different pool. |
| Restart on Error | Evaluated when a query encounters an error that allows it to be restarted automatically by the system. Queries are potentially restartable from the assemble, compile, acquire resources, and run states. Restartable (or "recoverable") queries may loop back into the cycle multiple times. They always restart from the assemble state. See Recoverable Error Codes.A small number of user-defined actions can be defined for evaluation when queries go into a restart state. These rules are mainly intended for logging purposes.Because restarted queries loop back through earlier states in the query life cycle, the rules for those states are evaluated and applied again. This behavior may cause the restarted query to acquire and run with exactly the same resources, more resources, or less resources. Queries restarted on error may result in the same error that the first attempt at execution produced. The default behavior defined by the global_restartErrorPolicy rule is to give each query 1 retry, running the query in the same resource pool as before. If this policy does not work well in your application, you may want to set up a rule that changes the query to use a pool with more memory, or in the case of flex pools, use the maximum memory available. See Restart Rule Examples.Note: If you are using CREATE WLM RULE, the SQL type for Restart on Error is restart_for_error. |
| Restart via Rule or Administrator | Evaluated when a query goes into a restart state that was triggered either by the application of a rule or by a RESTARTcommand run by an administrator. See also "Restart on Error."**Note:** If you are usingCREATE WLM RULE, the SQL type for Restart via Rule or Administrator is restart_for_user. |
| Runtime | Evaluated while the query is running (in the run state). These rules are processed for long-running queries only, at 5-second intervals. If a query runs to completion in less than 5 seconds, these rules are not processed at all. A number of different actions can be taken. Long-running queries can be intercepted and aborted, the priority of queries can be reset, queries can be moved to different pools, concurrency can be throttled, and query activity can be logged. |
| Completion | Evaluated once after all query execution steps are completed or stopped for some reason. Completion states are Done, Cancel, and Error. The main actions available at this stage are related to logging. |
Parent topic:Creating WLM Rules