Allocation Groups - Teradata Workload Management - 16.20

Teradata® Viewpoint User Guide

prodname
Teradata Viewpoint
Teradata Workload Management
vrm_release
16.20
category
User Guide
featnum
B035-2206-107K

In SLES 10, the priority scheduler uses enforcement priorities and allocation groups to manage resources. An allocation group (AG) is a group of workloads that share an enforcement priority (EP). The AG manages access to CPU resources based on the assigned weight from the EP. An EP is a label given to assign weights for the queries running in a workload. Each AG takes the EP of the first workload associated with it and after that, only workloads with the same EP can be associated to that AG. As a result, each AG is a collection of one or more workloads that share the same EP. Multiple AGs can use the same EP. You can group and manage AGs in resource partitions. The default allocation groups and any groups you create are assigned to resource partitions.

In SLES 10, Teradata Database uses default allocation groups L (Low), M (Medium), H (High), R (Rush) and the following EPs:
  • Tactical queries are short, critical queries with defined service level goals. They are typically single or few-AMP queries or all-AMP queries that consume less than 1 CPU-second per node.
  • Priority queries are important and have higher priority than most other work.
  • Normal queries are the average priority work running on the system.
  • Background queries run for work that does not have a response-time requirement.

You can change the default mapping by using the diagram on the Workload Mapping tab, where you can reassign workloads to other allocation groups and reassign allocation groups to other resource partitions. Allocation groups that contain workloads cannot be deleted.

Carefully consider the allocation groups you drag in and out of the tactical resource partition because this can have a significant effect on the amount of CPU available to the queries running in the allocation group. The tactical resource partition normally has a much higher weight than other resource partitions. If you move an allocation group containing long, resource-intensive queries into the tactical resource partition, those queries can consume a large amount of the available CPU, impacting queries running in other resource partitions. If you move a tactical allocation group out of the tactical resource partition, the queries running in the tactical allocation group are assigned a lower priority and may not meet their response-time goals.