Error message

Warning: Creating default object from empty value in _dxcontentbanner_set_details_blog() (line 206 of /appl1/devx/drupal/sites7/all/modules/devx/modules/dxcontentbanner/dxcontentbanner.inc).
Subscribe to Blog content and comments for carrie Latest blog posts

A state matrix is a construct that allows you to intersect your business processing windows with the health conditions of your system.  Why should you care about this abstraction?  The state matrix in TASM is the mechanism that supports an automated change in workload management setup as you move through your processing day, or should your system become degraded.  Not only is it automatic, but it's a significantly more efficient way to make a change in setup while work is running.

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?

Statistical information is vital for the optimizer when it builds query plans.  But collecting statistics can involve time and resources.  By understanding and combining several different statistics gathering techniques, users of Teradata can find the correct balance between good query plans and the time required to ensure adequate statistical information is always available.

This recently-updated compilation of statistics collection recommendations are intended for sites that are on any of the Teradata 14.0 software release levels.   Some of these recommendations apply to releases earlier than Teradata 14.0, however some rely on new features available only in Teradata 14.0.

Contributors:  Carrie Ballinger, Rama Krishna Korlapati, Paul Sinclair, February 12, 2013

As you approach full use of your AMP worker tasks, monitoring in-use counts becomes a more important exercise.  The ResUsageSAWT (SAWT) table provides a wealth of information about AWT usage when you need to dive into details.

ResUsageSAWT provides you with several categories of information, including AMP worker task usage and high-water marks broken out by work type, as well as message queue depth/ flow control frequency metrics. 

Most of us are aware of AMP worker tasks, and some of us are even obsessive about not running out of this finite resource.  But that’s on the AMP.  What about the tasks supporting user work on the parsing engine (PE)?  Should we be just as vigilant about what’s happening with tasks at the PE level?

Not really.  Here’s why.

I gave a presentation on AMP worker tasks at the Teradata User Group conference last week in Washington DC.   A question came from someone in the audience concerning FastExport jobs in response mode, and whether or not they were holding AMP worker tasks.  This post addresses that question.

Teradata 14.0 offers some very helpful enhancements to the statistics collection process.   This posting discusses a few of the key ones, with an explanation of how these enhancements can be used to streamline your statistics collection process and help your statistics be more effective.

For more detail on these and other statistics collection enhancements, please read the orange book titled Teradata 14.0 Statistics Enhancements, authored by Rama Korlapati, Teradata Labs. 

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.

Starting in Teradata 13.10, there is a single delay queue for all throttles.  This means that queries delayed by system throttles will reside in the same queue as queries delayed by workload throttles.  In earlier releases, delay queues were set up independently by type of throttle, and each workload throttle had its own dedicated queue.   

Bringing together all delayed objects into a single queue streamlines the entire throttling experience and makes it easier and more accurate to manage internally.  However, as a side-effect, the DelayTime field in DBQL needs a second look.  DelayTime takes requires slightly different interpretation in 13.10 than you gave it in earlier releases.

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 the particular conditions under which this may happen, and points to a simple adjustment you can make to keep it from happening again.   

Pages