Throttle Enforcement Options in Teradata Workload Management

Blog
The best minds from Teradata, our partners, and customers blog about whatever takes their fancy.
Teradata Employee

Throttles in Teradata workload management come in several different levels of inclusiveness. The easiest type of throttle to understand and create is the most restrictive, the workload throttle.   As part of the workload definition, you simply check the box that says to add a throttle on the workload.  Then you pick a throttle limit.  No classification criteria is required because a workload throttle will only cover requests that classify to that workload.  And there are no additional options allowed on a workload throttle.  Very simple.

 

The throttle type with the broadest scope is the system throttle. Depending on how you define it, a system throttle is able to incorporate all active requests coming into the database. 

 

Defining a system throttle is a little more involved than specifying a workload throttle. Not only do you have to select one or more classification criteria to express which requests you want the throttle to cover, but you also have to select an enforcement option for the throttle.  This posting is not going to advise you on how to use classification criteria for a system throttle, but it is going to explain what enforcement options are and the consequences of using them. 

 

But before we can take a close look at enforcement options, it will help to understand a few of behavioral characteristics related to system throttle classification.

 

What Happens When There Are Multiple Request Source Objects

 

If you want to reduce the scope of a system throttle from all requests that enter the database to a specific subset of requests, you do this by means of classification criteria. You can specify classification for the throttle based on one or several request source objects, such as Users or Profiles.  You can combine more than 1 object of the same type (10 Users, for example) or multiple different object types (one Users and one Profile, for example), or a more complex combination (multiple Users and multiple Profiles).

 

Starting in 13.10 here how multiple request source objects are handled:

  • If you have multiple criteria of the same type (User1 and User2, for example), they will be OR-ed together.
  • If you have multiple criteria of different types (User1 and Profile XYZ, for example), those criteria will be AND-ed. In other words User1 would have to be in Profile XYZ for User1’s queries to classify to such a throttle.

If you find this second bullet limiting, there is a new enhancement you can try out. Starting in 15.10 there is a special case that bend the rules on how multiple objects of different types are handled: 

  • Once you are on 15.10 or above, you have the option of specifying both a User name and Profile name for the same system throttle and then OR them together. The default option will still be AND.


User_Prof_OR.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Enforcement options are rules that control how a system throttle limit will be enforced. There are three different enforcement options:

  1. Collective Option:  The throttle counter will be applied collectively, a single level of throttling for all objects and all members within these objects (the default since 13.10). This is the most common enforcement option, and is taken as the default across most system throttles.
  2. Individual Enforcement:  Each object (Request Source or Target) will have its own independent counter. This results in the same behavior as if you had defined a separate system throttle for each associated object. 
  3. Members Option:  Each user within each object (if the object is a collection of users, such as an Account or a Profile) will have his own counter. This is useful if you want to impose a concurrency limit on a large group of users (for example, all users within a Profile) without having to add each user to the throttle independently. It also saves you from frequent maintenance activities against the throttle classification criteria as Users come and go.

The enforcement of the throttle will differ in scope depending on which enforcement option is selected. Whatever limit you define in the system throttle definition will be the limit that will be applied collectively, individually, or at the member level, as shown in the following graphic:

 


Enforcement_Options.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Enforcement Options in More Complex Situations

 

There are situations where all three enforcement options will behave the same no matter which option you select.   Here is an example:

  • If you have defined a throttle and classification is on one User, then all three enforcement options will lead to the same behavior.   That one User will have its own independent counter.

With more complex classification defined, here are some of the results you will see if you select different enforcement options:

  • If you have defined a throttle that incorporates several Users, then Collective will cover all the users in a single throttle, but Individual and Member will behave in an identical manner. They will both throttle each individual User independently.
  • If throttle classification is on a single Account or a single Profile (but not both) both Collective and Individual will behave the same. Both will use a single counter for requests whose User is part of that Account or part of the Profile. Member, on the other hand, will have a separate counter for each User within the Account or Profile.

In the following cases, each enforcement option will result in different behavior, as illustrated in the graphic above:

  • If classification is on multiple Accounts or multiple Profiles (but not both combined), then each different enforcement option will lead to a different behavior.
  • If you have defined a throttle with multiple different objects, such as 1 or more Users and 1 or more Profiles, then each enforcement option will be behave differently as well.

Remember that the Members option only plays a role if one or more of the associated objects represents a collection of users, such as Profile or an Account. The Members option will not play a role if the throttle is classified by Request Source criteria such as Client IP Address or Application, even if you select Members as the enforcement option.   In such a case you will get the behavior of the default Collective option.

 

Keep it Simple

 

If any of this is confusing to you, here’s my suggestion: Keep your throttles simple.   If you only associate a single Profile to a throttle, instead of several Profiles, you don’t have to think about whether to use Collective or Individual. I won’t make any difference. Your only decision will be whether to apply a single counter to the all requests from users within that Profile, or whether to give each user their own counter. If you want the former, one counter for all, then just go with the default of Collective.

 

When you might want to think harder about these enforcement options is if you need one limit across several Profiles (or across several Accounts). If you have more than one Profile (or more than one Account) that you would like to manage using a throttle, you will have to decide whether you want a separate counter for each Profile/Account (the Individual option) or weather you want one counter for all Profiles/Accounts combined (the Collective option). If you require a single concurrency level over several Profiles/Accounts, then you will need to associate all Profiles/Accounts to a single system throttle and use the Collective option.

 

You might also want to consider whether you want each User that belongs to each Profile/Account to be throttled independently and have their own counter. If that is the behavior you want, then you would want to select the Members option.

2 Comments

Carrie, glad to see a new blog post!

Teradata Employee

Johannes,

 

Thank you for you kind words and encouragement!  Hopefully more is on the way soon. 

 

Regards, -Carrie