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.

First, consider the two categories that are intersected in our state matrix:

  1. “Planned environments” represent different times of day when business priorities are expected to be different, such as night and day; weekday and weekend; regular, month-end or year-end. In the graphic below you can see that planned environments are on the horizontal axis of the state matrix.
  2. “Health conditions” represent the robustness of the system. When a node is down you might want throttle limits to be set differently, or priority setup to shift. Health conditions make up the vertical axis of the matrix. There may be two, possibly three health conditions that you want to treat differently in terms of workload management.

The intersection of these two categories, both which can necessitate setup changes, is referred to as a state. Although a simple state matrix is supplied by default, you will need to define your own specific planned environments and health conditions if you wish to make use of automated changes to workload management.  Once you define a state in Viewpoint Workload Designer, you can associate it to one or several different intersections, as shown in the figure above.


As mentioned above, a health condition or a planned environment can change as time passes or as the health of the system suddenly degrades. They can also change as result of a system event that the DBA sets up using TASM.   For example, you can define an event that will be triggered when Available AWTs reach a specified low level on some number of AMPs.  When you define a system event you give it an “action”, and one action could be to switch to a planned environment that throttles back low priority work. 

The figure below shows the workload attributes that can be modified when a state changes.


In the initial releases of TASM, users on busy systems sometimes experienced a delay in waiting for a state change to complete.  When going through a state change in releases prior to Teradata 14.0, a non-trivial level of internal work had to be performed:  All of the internal TASM tables that define the ruleset had to be re-read, all of the TASM caches had to be rebuilt, the delay queues were completely flushed, and all of the running queries on the system had to rechecked for adherence to throttles and filters.  Finally, all throttle counters had to be reset.

This overhead has been almost completely eliminated in Teradata 14.0.  With the state change optimization feature, there is minimal impact when doing a state change.  Internal tables do not need to be re-read and the delay queue is left intact.  There is no longer a need to recheck every running query.   A simple update to the existing cache is made to reflect the state information, and the new priority scheduler configuration is downloaded.  State-transition delay queue re-evaluation has been measured to be negligible overhead. So making frequent state changes is easily supportable, should you need to provide for that. 

Even if you are not using the state matrix and are not automating the predictable changes in your processing day, you can still throttle back low priority work on the fly.  However, doing so would require manually enabling a new rule set.  This is not a good idea.  When you change a rule set, interaction with Workload Designer is required to download and activate a new rule set, and far more re-evaluations are required to existing requests, delay queues, Priority Scheduler mappings, etc.

Changing workload management behaviors by enabling an entirely new rule set is not able to take advantage of the state change optimizations in Teradata 14.0. The delay caused by enabling a new rule set on a very busy system has in extreme cases been measured in in the minutes vs. the negligible overhead of state transitions.  Remember that an Activate of a new ruleset requires the reading of the ruleset from the TDWM database and activity which may contend with an already stressed system, whereas a state change does not require the TDWM database to be accessed.

Bottom line:  Get comfortable using the state matrix to design and automate your planned and unplanned changes, and enjoy a more efficient transition from setup to setup.  And for those of you already using the state matrix, you will have a smoother experience in the face of change once you are on Teradata 14.0.

Smarak0604 15 comments Joined 08/12
20 Jun 2013


If a System has more than 1 Ruleset, then which Ruleset is Active ? Cause, State Change affect the Working Values of each Rule within a Ruleset.

carrie 595 comments Joined 04/08
24 Jun 2013

The DBA has to activate the rule set he wants to be the active one.  This is done within the Viewpoint Workload Designer portlet.   Each rule set had a config ID number.   Viewpoint issues an API call that communicates the ruleset change to TDWM (in the database) so that that rule set can become the active one.  TDWM activites the rule set in the database, and does a complete reassessment of the system to determine what State the rule set should be in, based on the states defined in the new rule set. 
When a state change happens, it only impacts the rule set that is active.  Only the working values that apply to rules within the current rule set are eligible to be changed.  Nothing happens to working values in an inactive rule sets.  
The state change only has an impact on the rules within the rule set that are supporting the working values.  For example, a state change could cause a change to one rule:  a system throttle rule could be changed so that its limit will be reduced from 10 to 5.  However, none of the rules that define priority scheduler settings or that define utility throttles within that rule set will be changed.  In this example, the DBA had defined a state change to only impact one rule in the rule set.  He could have defined the state change to impact many rules within the rule set.  That is a design choice when the state is defined.
Thanks, -Carrie

31 Jul 2013

Hi Carrie,
My client is using teradata 13.10. I have currently four planned environments for the health conditions:
2.Business Hours (Mon-Fri, 8:00 am - 6:00 pm)
3.Loading hours (Mon-Fri, 6:00 pm - 11:59 pm)
4.Weekend loads (Sat-Sun, 6:00 am - 11:59 pm)
Now my client has asked me that for the first 6 days of the month the Business Hours State must be from 10:am - 6:pm and no matter whether it is weekend or not.
Can i handle this requirement with the State Matrix or not?
Because one option is to create another complete ruleset and activate it for first 6 days of the month and on7th day i shall deactivate that ruleset.
I want to do it with StateMatrix.
My second question is if my two Periodic states overlap at a time against one particular health condition (and both of them are not base) which of the two will get precedence?

Muhammad Fahad.

carrie 595 comments Joined 04/08
01 Aug 2013

Interesting question.
This should work for you by just adding a new planned environment that is for the first 6 days of each month.
At each TASM event interval, all system events are checked to see if a health condition needs to be changed.   After that, all defined planned environments are checked to see if a different planned environment should now be in effect.   If more than one planned environment meets to current conditions (in your terms they overlap), then the planned environment with the highest ID number takes precedence.  This will usually be the one in the rightmost position in the state matrix.   If you add you planned environment for the first 6 days of each month after your other planned environments were defined, this new one will naturally be added in the rightmost position and will naturally be higher in precedence that the others.
Notice that in your state matrix the Always planned environment is in the leftmost position, and will have an ID of 1, so it will always be the lowest in precedence order. The further to the right of there, the higher the precedence position becomes.
If you are not sure about which planned environment has the highest ID (or the higher ID amongst two that overlap), you can validate this by looking at tdwmdmp -a output.   Under the heading "State and Event Information" it will show you each Operating Environment (same as planned environment) with its OPENV-ID and the precedence order it has.
Overlap will not matter because when the check on planned environments are made at the event interval, all planned environments that match the current time-of-day/day-of-week will be considered, and the one with the highest precedence among them wins.
If for some reason your planned environment for the first 6 days of the month is not in the rightmost position in your state matrix, you can drag it into that position.
Thanks, -Carrie

05 Aug 2013

Thanks Carrie for your help

Muhammad Fahad.

Smarak0604 15 comments Joined 08/12
08 Oct 2013

Hello Carrie,

If more than 1 events are active at the same time, the action is decided by severity of the action. How is the Severity decided ?

I wish to know the same for Exceptions arising at the same time.

There is Workload Evaluation Order, does the same exists for Exceptions or Events also ?

carrie 595 comments Joined 04/08
09 Oct 2013

Two system events could be triggered at the same point in time.   At each event interval, a check is done to see if any system events have taken place.  It is possible more than one event has been triggered.   The actions of both will be initiated, but if the actions involve changing a state, then there is a precedence order that is followed.   You can see the precendence of different operational environments by looking at the State and Event information in tdwmdmp -a output.  
If you are talking about workload exceptions, that is something different and unrelated to events.  From the TASM for 14.10 orange book:
With the ability to have multiple exceptions apply to a workload, it is possible for multiple exceptions to be detected simultaneously against a single executing query. TASM will perform all the corresponding exception actions as long as they do not conflict. For example, TASM always executes all Raise Alert, Run Program and Post to QTable exception actions since they cannot conflict. Associated logging always occurs as well.
A conflict occurs when two exception actions to be performed are either:
•        Abort and change workload
•        Change to different workloads (e.g., change to WD-A and change to WD-B).
TASM follows these rules to resolve conflicting exception actions automatically when necessary:
•        Aborts take precedence over any change workload exception actions.
•        Within any conflicting exception list, precedence is given to the change workload with the timeshare then SLG tier then finally tactical workload management method. If two change workloads are both timeshare, the lower access level has higher precedence. If both have same access level then they are sorted alphabetically by workload name. If the conflicting change workloads are both using the SLG tier workload management method, the precedence is first determined by the lower SLG tier and if the SLG tier is the same, the workload with the lower workload share percent value. If both have same workload share percent value, then they are sorted alphabetically by workload name.
In all cases, TASM logs all change workload exception actions that were not executed and indicates that they were overridden. If you specified an abort action and any change workload exception actions, TASM aborts the query and logs all change workload exception actions as overridden.
Thanks, -Carrie

geethareddy 145 comments Joined 10/11
27 Dec 2013

hi Carrie,
Thank you for the article.
Q1) I have  a general best practices oriented question on activating the rule set on specific time. We are not following any specific time to enable the rule set on production. Do you recommend to activate rule set (especially on busy systems) during off peak hrs?
Q2) Which specific tdwm view/table gives me enough information on when a state has been changed? From tdwmdmp -a, I can see USER-OpEnv, is that means a "User Defined Event"? I think tdwmdmp has some old naming convention. Something like planned environment referred as Operating environment. Please clarify.
When it is specified as Days 0, Months 0, that means it is applicable for all the days?

  ID          EVENT NAME        CLASS       KIND      OPTIONS  ENAB
 ------  ----------------------  ------  ------------  -------  ----
 1              Event1               OPENV      PERIOD       0           Yes
                 Kind=All  From=1800  To=0100  Days=0  Months=0
 2              Event2               OPENV      USER-OpEnv  0           Yes
Q3) Having TASM on DBMS V14, i think we should not bother about ASE setup. I read from the DB admin manual that, "When TASM workload definition (Category 3) is enabled, the PG portion of the ASE is ignored for purposes of priority assignment. Instead, workload classification determines the priority of the request.
However, for the small amount of time that the first request of a session is being parsed prior to classification into a workload, the PG within the account string is used to establish priority."

From this above extract, I am not clear about what kind of work performed during that "small amount" of time.
For ex: I have a Batch User (BU1) under tactical enforcement priority who gets the resources from tactical resource partition. I defined the workload rule (WL1) on that user by defining the classification on ASE (on eg: $L$TACT&s7D&H). So in this case, eventually BU1 gets the tactical resouces, but I am not clear about that $L Performance Group defined in its account string and what exactly it plays a role for that "small amount" of time mentioned above in the extract.



carrie 595 comments Joined 04/08
02 Jan 2014

Q1:  If you have to change a rule set, it is better to do at off hours or non-busy times, as explained in the text above.
Q2:  TDWMEventHistory table shows the events that triggered the state change.  The TDWMEventLog shows that a state change has occurred and shows the old/new state id’s.  USER-OpEnv  means a "User Defined Event".   Also, USER-SysCon is a USER defined event within the health condition area.  Planned environment is the Viewpoint term for TDWM operating environment.  (and Health Condition is the viewpoint term for TDWM SysCon or System Condition)  When it is specified as Days 0, Months 0, that means it is applicable for all the days, yes.
Q3:  Performance group that is carried in the account string is no longer used in TASM.  PG within account string is no longer being used for session priority.   See the blog posting Elevating Parsing Priority to see how parsing priority is currently managed.
Thanks, -Carrie

You must sign in to leave a comment.