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 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:
Enforcement options are rules that control how a system throttle limit will be enforced. There are three different enforcement options:
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 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:
With more complex classification defined, here are some of the results you will see if you select different enforcement options:
In the following cases, each enforcement option will result in different behavior, as illustrated in the graphic above:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.