0 - 14 of 14 tags for workload

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.

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

How to find the SLGs associated with workloads in Teradata Viewpoint?Is there any tdwm/system table that provides the same info?

We are using TASM and Teradata 14.10 DB version.User is assigned to profile and profile is mapped to workload.

A single profile can be mapped to more than one workload.Based on query creteria, it will get qualified to run in a 

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.

Workload Designer has been updated to make it easier to understand and configure how resources are assigned to workloads. TASM 14.0 onwards SLES 11 uses a new method of workload resource allocation that is intended to simplify the process conceptually and procedurally. This post describes the new workload resource allocation user interfaces and how they can be used to perform some basic resource allocation.


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.

Is there a way to record Production SQL queries and workloads so that they can be replayed in another environment?
Kind regards,


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.


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.

This session provides an overview and demonstration of the TASM portlets and TASM feature functionalities.

TDWM is working and TASM is enabled on the system. I can see WDID in the DBQLogTbl however the OpeEnvId and SysConId are null. How can this be possible?
I think that when appropriate SysCon and OpEnv aren't selected then the 'Base' state is selected, which is comprised of 'Normal' SysCon and 'Always' OpEnv.