A Rejected Utility Job – When You Asked for Delays

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

Please note:  This content does not apply for sites on Teradata 13.10 or later releases.

Did you happen to catch my May 1, 2009, blog posting, titled ‘Utility Throttles – You Won’t Regret It’  I want to add an afterthought, a postscript, something I didn’t know about at the time I posted the blog. It concerns a characteristic of utility throttles that I can’t find documented anywhere, but that a co-worker alerted me to earlier this week.

If you’re thinking about using utility throttles, you might want to listen up.

This particular Teradata site defined a utility throttle rule that combined both MultiLoad and FastLoad jobs collectively, under one limit. In this case that limit was 20. The desire was for no more than 20 load jobs (whether MultiLoad or FastLoad) to run at one time. The action selected was Delay. This is a reasonable approach, and it worked almost all of the time.

However, they noticed that there were times when some load jobs were rejected instead of delayed.

The reason for this unexpected rejection has to do with the fact that there are actually two different limits being enforced when a utility throttle is active:

  1. A limit on the number of concurrent load jobs allowed to run within that category
  2. A limit on the number of AMP worker tasks (AWT) that are allowed to support all active load jobs

When you are using utility throttles, even though there is no setting, such as MaxLoadAWT, there is nevertheless a limit on the number of AWTs that will be allowed to be used to support those load jobs. If you have defined a utility throttle rule specific to one utility type, that one rule will be used to enforce both limit types (1 and 2 above). And if you have specified Delay on that rule, the action of delaying will apply to violations of both types of limits.

However, if you have a combined utility throttle, internal default rules (sort of like shadow rules) are set up for each individual utility type within that combination, to manage the AWT limit enforcement. These shadow rules will reject by default if a new load job would require greater than 60% of the total AWTs defined per AMP for supporting load jobs.

If you wish to have a delay action in the event that the AWT limit is reached, and you are using a combined load utility rule, then here’s what you will need to do: Create two additional utility throttles, one specifying just MultiLoad and one specifying just FastLoad, both with the same limit of 20 that the combined utility throttle is using. Specify Delay for both rules. These additional throttles will be unlikely to be used to limit concurrent load jobs, because the combined throttle will be more constrictive in most cases. But these new rules will override the shadow rules created to manage against the limit on the number of AMP worker tasks used for load jobs.

And you should be on your way to more confident load utility delays.

1 Comment
Enthusiast
Thanks for this explanation ! You are very helpful as always!