Classic design: The shell armchair by Charles Eames.
Applied Solution 1
Easy-to-use portlets streamline complex tasks.
Teradata Viewpoint has become a juggernaut with new state-of-the-art portlets coming out every three to six months. Both Teradata Labs and Professional Services are jumping on the bandwagon, delivering new capabilities through Viewpoint. This means Teradata brings innovations to clients sometimes faster than they can use them—a nice problem to have. The advances in Teradata Viewpoint make the DBA’s job easier and are clearly different from the cryptic command-line interfaces of many systems management products.
The workload-management portlets make up a vital collection of tools. This portlet bundle modernizes and expands the reporting, monitoring and configuring of the data warehouse workload management, formerly offered in Teradata Manager and Teradata Dynamic Workload Manager. For reporting and monitoring, the Workload Health and Workload Monitor portlets provide advanced visualization for DBAs and programmers. The elegant Workload Designer portlet supersedes Teradata Dynamic Workload Manager and simplifies the management of complex workloads.
More Than Just a Pretty Face
With no training and no manual, I figured out every screen in the Workload Designer portlet, defining rules and workloads like an expert. If a marketing guy can do it, how hard can it be? Admittedly, it takes a good DBA to correctly define workload rules for optimum performance. Nevertheless, Workload Designer’s ease of use pulls mixed-workload management out of the rocket-scientist category into a realm where any level of DBA can do it effectively. It’s a huge step forward delivered by Teradata Lab’s Glass Factory team. These user-interface experts and industrial artists make the Workload Designer portlet intuitive and uncomplicated.
To get started, the DBA clicks on functions, such as sessions or filters, when building a rule set. Rule sets are collections of related filters, throttles, events, states and workload definitions. The DBA can have several rule sets in progress and one in production. Figure 1 illustrates the rule set “Demo Rules” on the system called Topaz with several workloads defined, such as WD-Call-Center and WD-utility.
Click to enlarge
‘Simplicity Is the Ultimate Sophistication’ —Da Vinci
In many places in the Workload Designer portlet, runtime tasks must be classified before the correct rule can be applied. The DBA may need to filter out an unconstrained product join against large tables or may need throttles like “Limit marketing to five concurrent large queries on Monday mornings.”
With Workload Designer, incoming tasks are classified at runtime by:
- Request source. Whom does the query come from?
- Target. Which database objects is the task using and how?
- Query characteristics. How much CPU and I/O does the request need?
- Query band. What metadata is attached to the query?
- Utility. Is this a FastLoad, FastExport, ARC or MultiLoad job?
When the DBA defines rules such as workload filters and throttles, it is best to lead with request source and Query band classification criteria for precision. Target, query characteristics and exception conditions should be added when the other criteria do not fully identify an incoming request so that it is assigned to the appropriate workload.
For simplicity, Workload Designer uses a common classification subsystem. The same classification screens define rules for workload filters, throttles and session controls so fewer screens must be learned and used.
The sessions button allows the DBA to manage limits for FastLoad, MultiLoad, FastExport and ARC, thus putting restrictions on the number and type of concurrently running utilities. For example, the DBA might limit the number of mini-batch batch loads issued from account ABC during prime working hours to no more than three concurrent jobs. Incoming utility requests that exceed the limits are held in a delay queue until a running utility job finishes. The Workload Designer portlet makes this effortless once the DBA decides what’s needed.
Workload management is composed mostly of priorities and controls. Typically, interactive or small tasks get the highest priority and long-running tasks the lowest. Using the Workload Designer portlet, the DBA can see and change allocation group priorities quickly.
Click to enlarge
Here’s how: In figure 2, resource partitions slice up the system. Allocation groups (cells) are categories within a partition. And workloads are defined inside allocation groups. This display shows relative priority weights for each group. The DBA can easily drag the cell borders to change the amount of CPU available to the cell. But this simplicity should not lull the DBA into hasty changes—this display wields incredible power.
In this example, the internal workloads rush, high, medium and low map to the default R, H, M and L performance groups within the default resource partition of the Priority Scheduler. These workloads are not intended for active use by request-generating applications. Nevertheless, they must exist in support of internal work performed by the database itself. However, the RHML priority scheme is used with Teradata appliances to automatically manage end-user queries.
Appliances and More
Data warehouse appliances are designed to provide high throughput on large or complex queries and bulk data loading. Thus, Workload Designer behaves differently for appliances than for the Teradata Active Data Warehouse System.
For Teradata appliances, some functions of Workload Designer are turned off. Why? Appliances are designed to eliminate a lot of DBA labor. The DBA shouldn’t have dozens of controls, parameters, and tuning options to learn and worry about—a common problem on OLTP database products. Instead, appliances must be automated and self-managing. Teradata appliances are built to automatically optimize priorities and exception handling for the DBA. Consequently, Workload Designer provides fewer controls on an appliance.
In contrast, response time is a workload requirement when a data warehouse becomes active. To protect the 1- to 2-second query response time for such tasks as call-center queries, the DBA needs granular controls. For this, Workload Designer provides the ability to define new workloads and fine tune the exception controls. This requires more DBA skill and effort than with an appliance. Fortunately, the effort required is still much easier than parameter-weary database products.
‘Make Everything as Simple as Possible but No Simpler’ —Einstein
Teradata’s Glass Factory designers are uniquely skilled to produce easy-to-use, intuitive portlets. Their results are clear in the Workload Designer portlet that makes mixed-workload management less complex and more straightforward. Smart, experienced DBAs are still vital, but at least the tools make designing and controlling workloads as simple as possible.