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.

Discussion
vkbagare 5 comments Joined 02/10
09 Mar 2012

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?

Thanks,
Vinay Bagare

Best,
Vinay Bagare

carrie 285 comments Joined 04/08
09 Mar 2012

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

vkbagare 5 comments Joined 02/10
09 Mar 2012

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.

Thanks,
Vinay Bagare

Best,
Vinay Bagare

carrie 285 comments Joined 04/08
09 Mar 2012

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

gsoh 14 comments Joined 08/12
28 Sep 2012

Hi,

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?

carrie 285 comments Joined 04/08
04 Oct 2012

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

gsoh 14 comments Joined 08/12
25 Oct 2012

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?

carrie 285 comments Joined 04/08
29 Oct 2012

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

gsoh 14 comments Joined 08/12
08 Nov 2012

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

You must sign in to leave a comment.