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:
- “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.
- “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.
.jpg)
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.