Subscribe to Blog content and comments for carrie Latest blog posts

Teradata is a message passing system.  Messages are sent from parsing engines to AMPs, and from  AMPs to AMPs, and from AMPs to parsing engines.  That’s the key way that components in a shared nothing architecture pass data and work requests among themselves.

When a message arrives on an AMP and the message represents work that needs to get done on the AMP, that message is assigned a“work type”, depending on the importance of the work-to-be-done.  There are 16 different work types supported:  Work00 to Work15.      

Under usual conditions, all load utility jobs and all queries run using AMP worker tasks (AWTs) of the same message work types:  Work00, Work01, and Work02.  However, if you increase AWTs per AMP above a certain threshold, then all your utility jobs will be assigned to different work types and given their own reserve pools.   

If you are someone who monitors or is otherwise interested in AWTs and how they are being used, this posting describes changes related to your utility jobs, and what options you have for managing these changes.

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.

If you are user DBC or user TDWM and you log onto a Teradata Database, you might get treated somewhat differently than other users.  This posting describes what user DBC and user TDWM do, some of the special things about them, and when you can expect them to get treated differently.   We’ll also look at any implications in setting up workload management for these two special users.

This “Teradata Basics” posting describes the current dimensions of parallelism in the Teradata Database, and how they work together.

MLOADX is a new load utility enhancement introduced in Teradata Database 14.10 which is intended to overcome some of the limitations that are associated with standard MultiLoad.  This posting focuses on how workload management options will open up MLOADX for more expanded usage in Teradata Database 15.10.

Think about the priority part of workload management for a minute.

The settings that the administrator makes when defining priorities for different workloads are on the surface--things like workload allocation percentages and access level assignments.  They are easy to see.  Below the surface are “global weights”, which starting in Teradata Database 14.10 indicate to you the actual percentage of platform resources your workload will receive, based on its allocation.

But they do more than translate your settings to an expected resource share.  Global weights are used by the database to order the queues for several internal entities.  For example, the AMP worker task (AWT) message queue is now ordered by global weight in SLES 11. 

So it’s time you spent a few minutes taking a closer look at what global weights are, how the SLES 11 priority scheduler calculates them, and how you can influence them.

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.