Entering and Exiting a TASM State

Blog
The best minds from Teradata, our partners, and customers blog about whatever takes their fancy.
Teradata Employee

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?

Timers that control the movement between states

Before you use system events to move you between states, you will need to familiarize yourself with a few timing parameters within TASM, including the following:

  • System-wide Event Interval - The time between asynchronous checks for event occurrences.  It can be set to 5, 10, 30 or 60 seconds, with 60 seconds being the default
  • Event-specific Qualification Time – To ensure the condition is persistent, this is the amount of time the event conditions must be sustained in order to trigger the event
  • Health Condition Minimum Duration – Prevents a constant flip-flop between states,  the minimum amount of time that a health condition (which points to the new state) must be maintained even when the conditions that triggered the change are no longer present.

Entering a State

Let’s assume you have defined an AWT Available event that triggers when you have only two AMP worker tasks available on any five of your 400 AMPs, with a Qualification Time of 180 seconds.   Assume that you have defined the Health Condition associated with the state to have a Minimum Duration of 10 minutes, representing the time that must pass before the system can move back to the original state. 

TASM takes samples of database metrics in real-time, looking to see if any event thresholds have been met.  It performs this sampling at the frequency of the event interval. 

Once a sampling interval discovers the system is at the minimum AMP worker task level defined in the event, a timer is started.   No state change takes place yet.  The timer continues on as long as each subsequent sample meets the event’s thresholds.  If a new event sample shows that the event thresholds are no longer being met, then the timer will start all over again with the next sample that meets the event’s threshold criteria.

Only when the timer reaches the Qualification Time (180 seconds) will the event be triggered, assuming that all samples along the way have met the event’s threshold.  At that point TASM moves to the new state. 

Exiting a State

Returning to the original state follows a somewhat similar pattern.

The Minimum Duration DOES NOT determine how long you will remain in the new state, but rather it establishes the minimum time that TASM is required to keep you in the new state before reverting back to the original state.  

So when will you exit a state?

Event interval sampling continues at the event interval number of seconds all the while you are in the new state.  Even if the event threshold criteria is no longer being met and available AWTs are detected to be above the available threshold, once the move to the new state has taken place, the new state remains in control for the Minimum Duration.

After the Minimum Duration number of seconds has been passed, if event sampling continues to show that the AWT thresholds are being met (you still have at least five AMPs with only two AWTs available), TASM will continue to stay in that new state.  Only after  the first sample that fails to meet the event thresholds is experienced (once the Minimum Duration number of seconds has passed) will control be moved back to the original state.

The bottom line is that you will not return to the original state until the Minimum Duration time of the state's Health Condition has been passed, but you may not be returned then if the condition that triggered the event persists.

11 Comments

I have a small dought on DBQL log entries:

Why a simple (one time submitted) SELECT statement makes two records in DBC.DBQLOGTBL with diff QUERYID ?. You know my java team is submitted a single SELECT statement from JDBC into a teradata, and they found two entries recorded in DBQLOGTBL.  

Is there any reason behind this ???.

Teradata Employee

I am not an expert in the JDBC area, but my undestanding is that you will get two rows in DBQL with JDBC queries, one for the Prepare, and one for the query execution.  The row with the Prepare will not have any AMP CPU or any number of AMPs specified.  The row with the query will.

Thanks, -Carrie

Enthusiast

Hi Carrie,

As per the recommendation that i have read about these settings, for Event Management to function correctly, Workload Designer enforces the dashboard interval to be multiple of the event interval and the logging interval to be a multiple of the dashboard interval. Currently default (60,60,600 &60 for event,dashboard,logging & exception intervals respectively). Due to this, is there any negative efffect on data accumulation from memory to disk OR any delays will be experienced by WL Health portlet?

Please share your thoughts.




Thanks,

Geeta


Teradata Employee

Not that I am aware of.  I believe those choices for default interval settings were made so that they would be reasonably well-performing.

Thanks, -Carrie

Enthusiast

Thank you for confirming.

Enthusiast

Hello Carrie.. I wanted to confirm if my understanding (from my previous question regarding the priority schemes) is near correct.

Priority schemes can essentially be set for different states.

For instance, a certain Operating period "Day" has a different state, say "DayState", than Operating Period Night, say "NightState".

The priority scheme has been defined with Allocation group X with a 2% weight during "DayState" assigned to Workload B.

The priority scheme has been defined with Allocation group X with a 15% weight during "NightState" assigned to Workload B.

So, Workload 'B', would be subjected to different resource allowance during "Day" vs "Night" because of the different prioriry schemes for "DaySate" and "NightState".

Thank you

Sanjeev

Teradata Employee

Sanjeev,

Your understanding is correct.  Thanks, -Carrie

Teradata Employee

Hello All,

can someone guide me about the below issue,

i have two ruleset, one for day and another for night. i want that it change auto.

8:00 to 23:00 (day)

23:00 to 8:00 (night).

Also if there is some useful link for detials.

thanks.

Teradata Employee

Huzain,

Instead of using two different rulesets, you can create two different TASM planned environments in the same rule set and TASM will automatically change to the different state by time of day.   There is less overhead when you change states compared to when you change rulesets, plus it is automatic.

There is a little more information on changing TASM states in this blog posting on Developer Exchange:

http://developer.teradata.com/blog/carrie/2014/01/determining-precedence-among-tasm-planned-environm...

For more detail, the TASM orange book has an entire chapter on the State Matrix and automating setup changes.  And I believe the Viewpoint User Guide has some information about how to use Viewpoint Workload Designer screens to set up a state change. 

Thanks, -Carrie

Teradata Employee

Thanks Carrie, This was something which i need.

we have on other system on which we have applience TASM (TD SYSTEM 2700, RDBM 14 .10.10.04.06).

there is same requirment as metnioned above (Same User categorization w.r.t priority during day and night time), i have checked there is no such option available and we have just 3 built in performance groups, how can i do this on this Applience TASM.

Thanks.

 

Teradata Employee

In 15.0 you have an option to create multiple planned environments on the appliance platform.   When you get to that release you will be able to automate a change the priority of workloads from one Timeshare access level to another, or change the throttle limits by time of day or by user-defined function.  There is no way to automate those types of changes using Teradata Integrated Workload Management on the 2700 on 14.10. 

Thanks, -Carrie