0 - 50 of 60 tags for tasm


Am looking for some insights on setting appropriate CPU Skew Exceptions using Workload Designer.  Current VP version 15.11, Teradata 15.0.

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.

Hello,,, we  need restrict all client connection  connecting from a perticular IP address/server to Teradata Database .  Is there a way I can enable it in  TASM ?

A new database priority scheduler is introduced with the Linux SLES 11 operating system.


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.

This session covers the main topics of Workload Management on SLES 11 systems. 

Hi there,
I not have defined specific Utility Limits on one of our system, so I'm using the default system utility limits i.e.

System Default Utility Limits







FastLoad or MultiLoad


We have a relatively large datawarehouse (V14.0 Viewpoint V14.10 SLES 10).
We have a problem with certain types of query and certain source tables that causes us tremendous problem with regards system delays.

I am running an arcmain data copy, I see something like below in the arc/copy log file:





Workload Management is a critical component of balancing application demands and ensuring consistent application performance ...

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.

TASM gives customers the ability to manage Teradata resource usage and performance on platforms executing diverse types of work.

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.

Is there a setting to turn off TASM functionality ? I've looked in the TASM and TIWM orange books and searched the manuals some, but haven't not been able to find if this is possible / how to do it. 

A new database priority scheduler is introduced with the Linux SLES 11 operating system. This changes how workload priorities are managed within Teradata Active System Management (TASM).

This session provides an overview and demonstration of the TASM portlets and TASM feature functionalities, focusing primarily on the new features introduced in Teradata 14.0 SLES 10 and SLES 11.

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.

We have TASM setup to demote user queries from USERS-SHORT to USERS-MEDIUM and then USERS-LONG, after some CPU seconds consumed threshold.  We are seeing a number of queries get sent to our USERS_SHORT workload, only to be demoted to USERS_MEDIUM and then USERS_LONG.

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.

Hi All
We have a situation where a COGNOS user is submitting many queries to our live service and TASM is, correctly, placing them in the delay queue, once our concurrency throttle has been reached but the user is then "hogging" the delay queue with upto 50 queries waiting to be serviced. This is clearly unfair to other responsible users.

I'm trying to export our current TASM Ruleset from our production system and import it onto our staging system.  I keep receiving the following error.


Cannot import ruleset: The import file could not be parsed


Anyone know why?



I vaguely recall setting up TASM years ago before Viewpoint and we were encouraged to keep back a small percentage of CPU from the system.  I think we may have set the CPU limit for the system to something like 96%.  I do not recall where exactly that setting was made in Priority Scheduler.  We have since migrated from TASM using TDWM to TASM on Viewpoint

We have implemented a 'Penalty Box' workload within TASM for queries that are demoted after reaching specific exception criteria with the idea that they go into a workload which has a low CPU allocation.
We have seen a high % of CPU be taken into the Penalty box and remain with the query for a significant period.

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?

Defining workloads in TDWM may qualify as a TASM implementation but is just a small piece of the puzzle.  This presentation will look at this and all the other pieces needed to complete the picture.

Teradata Active System Management (TASM) is a powerful tool available to you that gives you unprecedented control over your Teradata system. Teradata 14.0 SLES 11 introduces Teradata Integrated Workload Management (TIWM), which, for the first time, provides workload management capabilities to customers without full TASM licensing.

Throttles are the most popular Teradata workload management option today. This webinar provides a simple yet thorough explanation of how these concurrency control rules actually work, reviewing the basics as well as focusing on important enhancements in the Teradata 13.10 and 14.0 releases.

I need to know that what kind of Workloads should we set for Responsetime Goal and what should go into Throughput goal.
I know SLG are for primarily for Reporting and analysis, and mustly depends on these two factors described above.

I'm trying to figure out what the settings under the Ruleset General View mean in the Viewpoint User Guide.
In particular the Blocker tab wjocj are "settings for responding to throttled blockers".  The system I am working on has
Block Cycles set to 1 interval
Block Action to release

Hello Masters,
How can I unlock or delete TASM Ruleset from "Local/Working" area in "Workload Designer", which is locked by other user? I tried it using "admin" user in Viewpoint but don't see any option to do it.

Do I need to look into some other place under "Admin" or am I missing any privileges?
Thank you,
Shrinivas Sagare

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.

Hi All,

Wondering is there a way to release all the users at once from the Delay Queue?


We are trying to implement a filter that would restrict users from returning more than 10,000,000,000 rows however there seems to be a restriction to 10 characters restricting us to 1,000,000,000, any ideas?

Rgds Paul


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

Hello Masters,

Is there any way to find out who, when and what changes done in TDWM/TASM rule set? We have DBQL enabled for user TDWM but DBQL is showing most of stored procedure call statement. It is not straight forward to analyze that data.

Any suggestion? I need to check it for TD13 as well as TD13.10 systems.

-- Shrinivas

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.

Hi All,

TDWM used to have a bypass list that excluded a particular user from all the rules (filters, throttles etc.) even if there was a need to exclude a user from one of the rules and not all. It was a sort of global bypass list.


In our shop we have Teradata with DBQL & TASM implementation.


Yesterday I extracted some data from DBQL for analysis that consists queries performance metrics along with work load and final workload definition for the a user.


Hi All,

I've two questions:

This article describes how Database Administrators can use Teradata Active System Management (TASM) to manage queries that execute against tables in Teradata Data Labs. This allows analysts to obtain the information they need without negatively impacting production applications.

Although this article focuses on TASM management, the general workload management guidelines can apply to other Teradata platform workload management strategies, not only ones running TASM.

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

We are receiving alerts from Viewpoint with no problem, however, the information being passed is not completely helpful just from the alert message. Is there anyway to change what is passed back in the message? SesNum is helpful but HoteID and ReqNum are useless. It would be great to get a UserName somewhere.


Teradata provides advanced Workload Management capabilities through Teradata Active System Management (TASM). However, some customers are still relying on only Priority Scheduler, without TASM's added capabilities. These customers can easily move forward to TASM. This article shows how to use Teradata Workload Analyzer (TWA) to migrate existing Priority Scheduler settings into TASM.

Teradata Active System Management (TASM) continues to evolve to increasingly higher levels of automation and usability. Come hear what new TASM offerings are available in release 13.x, and how you can best leverage these new features.

This workshop is led by a Sr. Professional Services expert who has delivered successful TASM & priority scheduler implementations. Priority scheduling concepts, TASM set up, Teradata Dynamic Systems Management, best practices when assigning priorities, and Teradata Manager monitoring tools are covered. The most common problems that must be corrected before TASM is turned on are also discussed. A sample mixed workload problem is used to illustrate the steps needed to analyze and correct the problem, such as DBQL inspection, capacity analysis, and query tuning. The session emphasizes real world best practices, tips, and traps. This education isn’t found in books -- it only comes from top experts.