Enforcement Priority: Soft, Hard, or Just Window-Dressing?

The best minds from Teradata, our partners, and customers blog about relevant topics and features.
Teradata Employee

If you are a TASM user, there is an option that springs up when you create a workload, labeled Enforcement Priority. The option name sounds a little more intimidating than it actually is. I’d like to take this opportunity to explain what enforcement priority is, what it actually does, and what it doesn’t do, and just how seriously you should take it.

There are four enforcement priorities, and every workload you define must be assigned one of those four. Enforcement priority doesn’t have anything to do with how resources are allocated, neither does it provide a priority boost to the more important work, at least not directly (I’ll explain what I mean by “not directly” a little further down). Rather, it is a way of for you to characterize and label the relative importance of the work running in that workload.

The four enforcement priorities to choose from include:

  1. Tactical: For very short, critical queries that have a defined service level expectation.
  2. Priority: For important work that needs to complete more quickly than most other work.
  3. Normal: For average priority work (the default).
  4. Background: For work that doesn’t have a response time requirement

In Viewpoint Workload Designer, select the General tab under Workload and you can see where to establish enforcement priority for a workload.

For the most part, enforcement priorities are passive. They are a method of grouping workloads with similar importance. Viewpoint uses enforcement priority to group and report on workloads, for example. However, there are a couple of ways in which they play an active role:

  • Priority scheduler allocation groups support multiple workloads only when they have common enforcement priorities: You are only allowed to map multiple workloads to the same priority scheduler allocation group if those workloads share the same enforcement priority. If you have an allocation group with a relative weight of 15% and you have assigned a workload with a Priority enforcement priority to that allocation group, you are then prohibited from mapping a different workload to that allocation group unless it also has been defined with an enforcement priority of Priority.

  • Special performance advantages to workloads with Tactical enforcement priorities. An additional active role for enforcement priority has to do with special performance boosts that are based on enforcement priority. This only applies to workloads given the Tactical enforcement priority. In Teradata 13.0 and 13.10, any workload that is given a Tactical enforcement priority will automatically be given an expedited status. This expedited status allows the workload’s queries to make use of special reserved AMP worker tasks pools (if they have been defined), as well as other internal database prioritizations. 

Enforcement priority was so named because at the time of the first TASM release enforcement priority was intended to be used in some future release to play an active part in influencing access to resources. However, with the emergence of Linux SLES 11 and a new priority scheduler for the Teradata Database, enforcement priority has been replaced by some of the new features and capabilities that SLES 11 offers.

So today, think of enforcement priority as primarily documentation, a method of grouping similar workloads for reporting and viewing purposes, with Tactical being the only case of any active, performance-related benefit. In fact many Teradata TASM users simply use the default enforcement priority of Normal for all their non-tactical workloads, so they can more easily move them between allocation groups, as tuning necessitates.

One thing I want to add, before I forget it. When you migrate from Linux SLES 10 to SLES 11, enforcement priority will play a small role in the automatic migration that takes place from the old priority setup to the new priority setup. Once again, this only applies to Tactical workloads. Any workload with a Tactical enforcement priority in SLES 11 will automatically be given a special very high priority positioning within the SLES 11 world.

So the bottom line on enforcement priority is that as long as you get your tactical workloads labeled correctly, it is not going to impact your performance or the balance of your work no matter which enforcement priorities you assign to the other workloads. However, you may find some benefit in the grouping that is done using enforcement priorities when it comes to viewing or filtering your workloads in Viewpoint.

Hi Carrie,

I had a question on Tactical expedited workload on V12.
If I have a workload w/ enforcement priority of Tactical but is not part of Tactical resource partition, will these be expedited too?

Vinay Bagare
Teradata Employee
Hi Vinay,

On your release (12.0), a workload with a tactical enforcement priority can be placed in any resource partition you like, whether or not it is named "Tactical". The enforcement priority does not really enforce anything in your situation. Neither are workloads/allocation groups automatically expedited if you give them an enforcement priority of tactical. (In 13.10 they will be.) You must individually select which workloads/allocation groups you wish to be expedited.

If you expedite a workload/allocation group, you can then after the fact move it to a different resource partition if you wish. The limitation that comes with enforcement priorities is that you cannot have workloads with different enforcement priorities mapping to the same allocation group. But if the tactical workload has its own dedicated allocation group it doesn't make any practical difference which resource partition you move it to.

That said, many sites find an advantage in keeping the tactical workloads together in a single high-weighted resource partition. That provides an easy way to ensure their high relative weights, and has been found to be a clearer way to understand and tune the priority setup. But it is not a requirement to do so.

Thanks, -Carrie
Thanks Carrie!

I always thought and saw that anything that is not part of Tactical Resource partition can never be expedited.
I don't even see an option to expedite such cases in Viewpoint/TDWM.

I learned from someone that we could expedite these too.

Vinay Bagare
Teradata Employee
Hi Vinay,

TDWM and Workload Designer both seem to enforce the rule that only tactical enforcement priority can be expedited. But I am not aware of any restriction about what resource partition the workload resides in, as long as it’s enforcement priority is tactical. I don't have access to a T 12 system, so I cannot see what you are seeing, but earlier today I got on a Viewpoint 13.10 system and it allowed me to move a tactical enforcement priority workload into the standard resource partition. I did get a warning, but it works. So I'm pretty sure the resource partition doesn't make any difference in terms of a workload being expedited.

Let's continue offline.

Thanks, -Carrie

I have question about TDWM Portlet Setting.
What is the difference about
CPU Limit at RP group and CPU Limit at AG Group,
If I setting with 80% at some Workload and I have two sub-AG.
If I add 80% respectively in the two AG when what happens?
Teradata Employee
A CPU limit placed on an RP (resource partition) will limit the CPU used by all the allocation groups active within the RP. A RP-level CPU limit will not be exceeded by the combined CPU usage of active allocation groups running within that RP.

A CPU limit placed on an AG will only restrict CPU usage within that AG.

If you want to restrict two AGs that are part of the same RP to a combined 80% CPU usage, then place the 80% CPU limit on the RP. If you want to restrict each AG to 80% individually, then place an 80% CPU limit on each of the two AGs. In that case, where each of two AGs have an 80% CPU limit, it is not likely that either will ever be able to reach 80% CPU limit in usage, because there is only 100% CPU on the nodes. So usually AG-level CPU limits are defined to be much lower than 80%.

There is no CPU limit allowed on the workoad, only on the allocation group. You may have several workloads running under the control of the same AG. In that case all the workloads mapping to that AG will be under the control of the AG-level CPU limit.

Thanks, -Carrie
Thanks Carrie,
I have another question.
If I setting each 20% CPU Limit at 2 AG in 1 RP with in 20% CPU Limit, Does it happen? Is there a meaning?
Teradata Employee
If you have two allocation groups in RP1 and each of them has a 20% CPU limit, and in addition RP1 itself has a 20% CPU limit, then the work of all of the allocation groups under RP1 will be limited collectively to 20%. For example, AG10 uses 12% and AG11 uses 8%, something like that.

However, only when just one of thoes 2 AGs are active within RP1 will that AG ever reach 20% of CPU usage, so the limit of 20% at the AG level is not providing any value in the case you describe. It will not hurt you to have it in place, but it will not add value.

If you want to limit the combined usage of both AGs, then place the CPU limit on the RP-level. If you want to instead limit each AG within RP1, then place the AG level CPU limits on the two AGs.

You could also make the CPU limit on the RP (which limits all AGs within the RP collectively) some higher percent, and then the individual AGs within that RP at some lower percent. But I see no value in setting them all the same.

It is better to first determine what you want to limit from the business perspective, and by how much, then add the CPU limits.

Thanks, -Carrie
You should know that your advice can be helpful.
Thanks, GS

hi Carrie,

We have almost 6 different tactical workloads (WL1,WL2,3,..6) for different apps in Tactical RP. Yes for all these the enforcement priority is Tactical. So they fall in to tactical RP. So having said that, the Performance Group (PG) defined in the account string (AS) is not going to effect here irrespective of what kind of criteria i have followed, right?

For ex: (i am giving just 3 examples here for those 6 WLs criterias')

1)WL1 is defined on users who ever assigned for an account string ($M0$WXYZ&S&D&H)under tactical enforcement priority.

In this case, I assume users U1, U2 & U3 with AS $M0$WXYZ&S&D&H.

So when U1 logs in to the system and submits a query, it will be allocated to tactical RP.

2) WL2 is defined for users logging in via few IP addresss under tactical enforcement priority. I assume users U4,U5, & U6 with AS  $L1$ABCD&S&D&H.

3) WL3 is defined on list of user ids (U7,U8,U9). I assume users U4,U5, & U6 with AS  $M1$OPQR&S&D&H.

In my above 3 WLs case, the PG is not going to effect right? Here Medium and Low PGs falls in to RP0 (Default RP) with 25% system resouces. Where as Tactical RP falls in to RP1 with 50% of total system resources.

My 2nd question:

In schmon settings (as shown below), I noticed the PG for these WLs are recorded as PGWLnnnn(n is a number). Ideally for those 6 WLs the PG mentioned in the AS should be shown under PG section for the schmon settings for PG section below. Any idea why these recorded like PGWLnnnn (instead of WXYZ, ABCD, OPQR...)

PG information of those 6 Tactical WLs :

Id PG Name RP Type Milestones Allocation Groups[0-7]
0 L 0 S 0 1
1 M 0 S 0 2
2 H 0 S 0 3
3 R 0 S 0 4
4 PGWL1115 2 S 0 5
5 PGWL1095 1 S 0 9
6 PGWL1116 1 S 0 7
7 PGWL1102 1 S 0 7
8 PGWL1105 1 S 0 7
9 PGWL1091 1 S 0 9
10 PGWL1084 1 S 0 7
11 PGWL1089 1 S 0 7
12 PGWL1073 1 S 0 7
13 PGWL1113 2 S 0 5
14 PGWL1085 1 S 0 7
15 PGWL1083 1 S 0 9
16 PGWL1092 1 S 0 8
17 PGWL1101 2 S 0 5
18 PGWL1117 1 S 0 9
19 PGWL1067 2 S 0 5
20 PGWL1090 1 S 0 10
21 PGWL1078 2 S 0 5
22 PGWL1119 1 S 0 8
23 PGWL1076 1 S 0 9
24 PGWL1111 1 S 0 10
25 PGWL1107 2 S 0 5
26 PGWL1066 1 S 0 8
27 PGWL1080 1 S 0 9
28 PGWL1096 1 S 0 10
29 PGWL1070 1 S 0 10
30 PGWL1065 1 S 0 8
31 PGWL1087 1 S 0 9
32 PGWL1077 1 S 0 9
33 PGWL1074 1 S 0 9
34 PGWL1071 1 S 0 10
35 PGWL1103 1 S 0 9
36 PGWL1075 1 S 0 10
37 PGWL1118 1 S 0 6
38 PGWL1097 1 S 0 7
39 PGWL1121 1 S 0 7
40 PGWL1120 0 S 0 1


Id PartitionName Weight Limit
0 Default 25% none
1 DSS 25% none
2 Tactical 50% none


related to my first question, I recently heard that, with SLES 10, the priority scheduler uses Enforcement Priority (EP) and Allocation Groups(AG) to manage resources. And AG use the EP to allocate the resouces based on the weight assigned under EP. Is this applicable to Teradata DB version 14 also?

Teradata Employee

Response to your first question:


If you are using TASM,  workload classification criteria alone determines the workload (and thus the priority) that a query will execute under.  The performance group name in the account string does not determine priority with TASM.  If tactical queries classify to workloads within the tactical RP, it doesn't matter what the performance group name in their account string is.  The performance group name in the account string will be ignored. 

For each workload you create in TASM, TASM creates a new performance group under the covers that that workload will use for its queries.  Those TASM-generated performance groups all start with "PGWL...".    If you are using TASM, the performance group names in the account strings do not play a role and those account string performance group names will not show up as valid performance groups in the schmon output.

Thanks, -Carrie

Teradata Employee

Response to your second question:

Enforcement priority and allocation groups no longer apply only when you move to SLES 11 operating system.  They only apply to SLES 10 priority scheduler.

For information and background on how SLES 11 priority scheduler works, please read the SLES 11 Priority Scheduler orange book.

Thanks, -Carrie


Fantastic! I am so glad that my puzzle has been resolved. Thank you very much Carrie.

Actually I read from the DB admin manual that, "When TASM workload definition (Category 3) is enabled, the PG portion of the ASE is ignored for purposes of priority assignment. Instead, workload classification determines the priority of the request. However, for the small amount of time that the first request of a session is being parsed prior to classification into a workload, the PG within the account string is used to establish priority."

From this above extract, I am not clear about what kind of work performed during that "small amount" of time.

For ex: I have a Batch User (BU1) under tactical enforcement priority who gets the resources from tactical resource partition. I defined the workload rule (WL1) on that user by defining the classification on ASE (on eg: $L$TACT&s7D&H). So in this case, eventually BU1 gets the tactical resouces, but I am not clear about that $L Performance Group defined in its account string and what exactly it plays a role for that "small amount" of time mentioned above in the extract.

There is a reason why i am asking this question so persistingly. We have current Account strings almost 800+ where almost 750+ are starts with $M on prod. There are some new users still not yet defined with any ASE. So my ONLY concern here is, how do i need to set them up. I understood that even if i create them with $R or $H it does not matter, becuase everything is controlled by TASM. And i am also considering that this is true for both APPLIANCE and ENTERPRISE platforms. Please clarify this for me.

Teradata Employee


I think I also mentioned this in an earlier response to you on Automated Demotions on the Appliance:  What are Query Milestones?, the Appliance platform does not have workloads like TASM, and does not have workload classification.   Therefore the appliance will use the performance group name in the account string to determine priority.

You can ask your account team for a complete list of workload management differences between the Appliance and the EDW platforms, if needed. 

Thanks, -Carrie


Yes Carrie, i just visited your comments on my previous questions. Sorry might be i rephrased the question diferently here.

Once again thank you for your time on my questions.