Tactical workload exceptions are in place to prevent tactical queries from consuming unreasonable amounts of resources.  It is important to have this protection because the super-priority and almost unlimited access to resources given to work running in the Tactical tier with SLES 11 is easy to abuse.   

Have you ever found yourself confused when setting up classification criteria for a new workload in Teradata?  You’re not alone.  This posting discusses the main principles at work when it comes to combining different classification criteria.  It also provides some general tips to help you do effective, clean, predictable classification, whether on your workloads, your throttles or your filters.

You may want to skip over this posting. 

Unless you’re curious about some of the more obscure workload classification conventions used by TASM and TIWM.

As of Teradata Database 14.10.05 and 15.00.03, a simplified approach to determining which workload will support session management and parsing has been adopted  This posting describes this more straightforward approach which will be used starting in these 14.10 and 15.0 releases, and going forward in all future releases.

An earlier posting titled:  “A Closer Look at How to Setup a Parsing-Only Workload”  explains how session and parsing workload assignment takes place prior to this more simplified approach.  If you are on an earlier release, please see that posting from December 2014.

Note:  This content only applies to releases earlier than Teradata Database 14.10.05.  If you are on Teradata Database 14.10.05 or later releases, please look at the more recent posting titled:  A New Simplified Approach to Parsing Workload Selection.

When you think about priorities, you probably focus your attention on AMP work.  Whether you are using Teradata Active System Management (TASM) or Teradata Integrated Workload Management (TIWM), AMP work performed by requests are typically spread across different workloads, with their priorities based on the importance of the work to the business and how long you expect the work to run.

Parsing engine work on behalf of a query runs within a workload as well.  Work performed on the parsing engine is typically very quick and requires very few resources.  So why not run some, or all, of your parsing activity in a very high priority workload where it may be able to complete sooner when your system is busy,  just as you do with your short, critical AMP work?  This posting will explain how parsing priority is determined, and will illustrate the steps involved in increasing parsing priority.

How does TASM enforce rules such as classification and workload exceptions against User Defined Functions?  What about table functions and table operators, some of which do their work outside of Teradata?  How far can you rely on TASM classifications using estimated processing time in these cases?  Will there be accurate resource usage numbers reported to support workload exceptions on CPU or I/O?

These are some of the questions that need answering if you are extending the use of simple or more complex user-defined functions on your platform.

Most Teradata systems support different processing windows, each which has a somewhat different set of business priorities.  From 8 AM to 12 noon the most important work may be the Dashboard application queries.  But from 12 noon to 6 PM it could be the ad hoc business users.   At night maybe it’s the batch loads and reporting.   Planned Environments function within the TASM state matrix to support the ability to automatically manage changes to workload management setup during those different windows of time.

I just returned from the 2013 Teradata user group Partners Conference in Dallas.  One of the technical topics that I presented at the conference was throttle rules and how they work.  Throttles provide concurrency control in TASM, both on the EDW and the Appliance platforms.   I'd like to share few points about enhancements to throttles in Teradata 14.0 and 14.10 that I discussed at the conference,  in particular automatic throttles.

In earlier postings I’ve described how TASM system events can detect such things as AMP worker task shortages, and automatically react to change workload managements settings.   These system events tell TASM to look out for and gracefully react to resource shortages without your direct intervention, by doing things like adjusting throttle limits temporarily downwards for the less critical work.

This switchover happens as a result of TASM moving you from one Health Condition to another, and as a result, from one state to another state.  But how does this shift to a new actually state happen?  And under what conditions you will you be moved back to the previous state?

How do you pick the number of sessions to assign to your utility jobs?  Chances are you guess.  In Teradata 13.10 the task of deciding the number of sessions has been moved inside the database, meaning one less thing for you to worry about.  Read on for a quick intoduction to how this feature works.

If you are using utility throttles in Teradata 13.10 to manage concurrency of your load jobs, any delay action against the utility job's unit of work will happen cleanly at the beginning of the load job.  However, there may be times where the load activity can be unexpectedly held up after the utility has begun execution.  This posting describes

AMP worker tasks are the dedicated tasks inside each AMP that get the database work done.  As there are a limited number, this important resource is actively monitored by DBAs on busy systems.  TASM system-level events can take care of the monitoring for you, and based on a threshold you have set set, will trigger changes in workload management setup to manage the AWT shortage.  How AMP worker task events do their monitoring has changed in Teradata Database 13.10, and this posting describes those changes.

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.

Teradata's Workload Management offerings have drastically changed over the past few years.  Further, not only has the functionality changed, but the product delivery mechanisms have changed as well.  This blog entry will focus on these delivery mechanisms, and how they have changed.

Reserving AMP worker  tasks (AWT) for tactical applications is a technique to protect business-critical, short queries, when the platform is experiencing AMP worker task exhaustion.   If you are thinking about reserving AWTs, there are two different settings for which you will be required to provide values.  This posting discusses what these two settings