0 - 37 of 37 tags for workload management

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.

This webcast provides an overview of the Teradata Workload Management, consisting of Teradata Integrated Workload Management and Teradata Active System Management (TASM).

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

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 session covers the main topics of Workload Management on SLES 11 systems. 

This session explores the new options available for setting hard limits at different levels in the SLES11 priority hierarchy.

Have you ever wished for a magic wand that could quickly point out the missing, stale, and unused statistics for you?

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.

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.

I have a scheduled job(a set of CPU intensive statements) which should run under a high priority workload during off business hours and should run under a low prioirity workload when the sytem is busy during business hours.

This article is the official release announcement for Teradata Viewpoint 15.00 with an effective release date of April 9th 2014. The Viewpoint 15.00 release has a whole new look and feel. The upgraded infrastructure embraces newer web technologies, improves performance, and enhances user accessibility, interaction, and discovery. As the versioning suggests, Viewpoint 15.00 supports the Teradata Database 15.00 release. 

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

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.

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.

If you are using Teradata on one of the 1xxx or 2xxx platforms, be aware that query demotions are automatically built into your workload management scheme.   Because I’ve had a few questions about what these so-called "query milestones" are and how they actually work, I’d like to explain this functionality and discuss its trade-offs. 

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.

The purpose of this series was to give you some basic queries that I use to provide me with a quick snapshot of how well tuned an EDW is from a workload analysis and database tuning perspective.

The four topics were (direct links are provided at the end of the article):

  • Part 1 - Excessive Use of String Manipulation Verbs
  • Part 2 - Analyze Secondary Index Usage
  • Part 3 - Statistics Analysis
  • Part 4 - Compression Analysis

Have you tried them yet??

Penalty boxes have been around for years.  They come in all shapes and sizes.  Their single, focused purpose is to lock away bad queries and thereby protect good queries, while not condemning the bad ones to the ultimate penalty of being aborted.  If you’re using penalty boxes, I want to encourage you to look inside them once in a while, and open your eye

Ok, so I shouldn’t even need to broach this topic, as I’m sure you have all heard it before: compress, compress, and compress.

In Part 3 of this series, we will take a quick look at how statistics are implemented and maintained at your site.

Statistics Collection can be a complicated and very deep-dive topic, with discussions on the frequency of collection, whether to use sampled stats, automation strategies, etc. This analysis is not going to go that deep, it is a high-level look at the statistics on the tables, and I am looking for just two things:

  • Are statistics applied to the tables or missing?
  • For those that are applied, is there consistency in the application and collection process?

In Part 1 of this series, we looked at the Excessive use of String Manipulation Verbs in a query. Here is that link in case you missed it:

Last month I talked about things that don’t honor a CPU limit, and explained what a CPU limit is. This month I’d like to look at CPU limits from a slightly different perspective—What happens when you define CPU limits at multiple levels?

Maybe you want to ensure that your sandbox applications never use more than 2% of the total platform CPU. No problem! Put a CPU limit of 2% on them. Or maybe you’ve got some resource-intensive background work you want to ensure stays in the background. CPU limits are there for you.

Teradata is very pleased to announce the official release of Teradata Viewpoint 13.02 effective January 8th, 2010!

We all know the benefits of identifying and fixing badly performing workloads. Many sites use the common method of identifying the top n highest consuming or skewed queries (often the same queries) and fixing those.

Chances are that if you’re into workload management at all, your using at least one throttle. Maybe you are using more. On the other hand, maybe you’re just thinking about it. Object Throttles (as opposed to Workload Throttles) allow you stray from the straight and narrow, because they offer you an array of options and can be used creative combinations.

The question of what Estimated Processing Time actually is comes up a lot. For example, the DBQLogTbl table carries an “EstProcTime” Value. If you are EXPLAIN-savy, then you’ve bumped up against “Estimated Time” numbers in almost every step of every query plan you’ve ever looked at.

Yeah, I know. All you need is another “thing to remember to do” following your upcoming hardware upgrade. As if your “must do” list wasn’t long enough already.