Teradata Workload Analyzer

Transcription

Teradata Workload Analyzer
User Guide
Release 14.10
B035-2514-082K
March 2013
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, Active Enterprise Intelligence, Applications-Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast, Gridscale,
MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, "Teradata Raising
Intelligence" logo, Teradata ServiceConnect, Teradata Source Experts, "Teradata The Best Decision Possible" logo, The Best Decision Possible,
WebAnalyst, and Xkoto are trademarks or registered trademarks of Teradata Corporation or its affiliates in the United States and other countries.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
Apache, Apache Hadoop, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation
in the United States and/or other countries.
Axeda is a registered trademark of Axeda Corporation. Axeda Agents, Axeda Applications, Axeda Policy Manager, Axeda Enterprise, Axeda Access,
Axeda Software Management, Axeda Service, Axeda ServiceLink, and Firewall-Friendly are trademarks and Maximum Results and Maximum
Support are servicemarks of Axeda Corporation.
Data Domain, EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of Oracle.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
Hortonworks, the Hortonworks logo and other Hortonworks trademarks are trademarks of Hortonworks Inc. in the United States and other
countries.
Intel, Pentium, and XEON are registered trademarks of Intel Corporation.
IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation.
Linux is a registered trademark of Linus Torvalds.
LSI is a registered trademark of LSI Corporation.
Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States
and other countries.
NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates.
QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.
Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Used under license.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademark of SPARC International, Inc.
Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and
other countries.
Unicode is a registered trademark of Unicode, Inc. in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN "AS-IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION
MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
The information contained in this document may contain references or cross-references to features, functions, products, or services that are not
announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions,
products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or
services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated
without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time
without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document.
Please email: teradata-books@lists.teradata.com.
Any comments or materials (collectively referred to as "Feedback") sent to Teradata Corporation will be deemed non-confidential. Teradata
Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform,
create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata
Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including
developing, manufacturing, or marketing products or services incorporating Feedback.
Copyright © 2005-2013 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
This book provides information about Teradata Workload Analyzer, which is a Teradata®
Tools and Utilities product. Teradata Tools and Utilities is a group of products designed to
work with Teradata Database.
Teradata Workload Analyzer (Teradata WA) is a tool that analyzes and generates candidate
workloads from a Windows PC. Teradata WA provides three major areas of guidance:
•
Recommending workload group definitions. The DBA (database administrator) guides
these definitions based on business knowledge and Analyzer-assisted recommendations
based on existing workload mix and characteristics
•
Recommending appropriate workload goals
•
Recommending workload to AG (allocation group) mapping plus priority scheduler
weights
Audience
This book is intended for use by:
•
Database administrators responsible for managing the Teradata Database
Supported Releases
This book supports the following releases:
•
Teradata Database 14.10
•
Teradata Tools and Utilities 14.10
•
Teradata WA 14.10
Note: See “Displaying Information About Teradata Workload Analyzer” on page 33 to
verify the Teradata WA version number.
Note: Teradata WA 14.10 supports the currentTeradata Database version and versions 14.0
and 13.x. (It does not support versions of Teradata Database earlier than 13.x.) However,
when used with Teradata Database 13.x Teradata WA 14.10 is limited to its 13.x features,
— that is, only those features supported by the earlier database.
Teradata Workload Analyzer User Guide
3
Preface
Prerequisites
To locate detailed supported-release information:
1
Go to http://www.info.teradata.com/.
2
Under Online Publications, click General Search.
3
Type 3119 in the Publication Product ID box.
4
Under Sort By, select Date.
5
Click Search.
6
Open the version of the Teradata Tools and Utilities ##.##.## Supported Platforms and
Product Versions spreadsheet associated with this release.
The spreadsheet includes supported Teradata Database versions, platforms, and product
release numbers.
Prerequisites
The following prerequisite knowledge is required for this product:
•
Relational database management systems
•
Basic concepts of the Teradata Database
•
Teradata SQL
•
Connectivity software, such as CLIv2
Changes to This Book
The following changes were made to this book in support of the current release. Changes are
marked with change bars. For a complete list of changes to the product, see the Teradata Tools
and Utilities Release Definition (B035-2029) associated with this release.
Date and Release
Description
March 2013
14.10
Updated versions and copyright date.
Documented new SLG Tier hints report added
to Existing Workload Analysis.
Documented support for new COLLECT
STATISTICS statement type.
Documented support for classifying TDWM
workloads by UDF and UDM.
4
Preface
Additional Information
Date and Release (continued)
Description
August 2011
14.00
Changes to this release include:
New options added to convert existing PDSets as
workload definitions based on Accounts or on
Performance Groups.
The Candidate Workload Report window now
has a Distribution Charts tab that displays the
CPU, IO, and Query Volume statistics in a pie
chart with a legend pop-up window.
Documentation now reflects that support for
Windows 2000 has been removed.
Starting with TTU14.00, the DIP script
(DIPTDWM - TDWM Configuration) sets
up the TDWM tables, but TWA itself
handles setting up the required objects
(procedures and macros) for client
operations.
TASM 14.00 SLG Responsive Priority Scheduler
support added for Linux SLES11 platforms.
Interface changes documented in Chapter 7.
Additional information that supports this product and Teradata Tools and Utilities is available
at the web sites listed in the table that follows.
Type of Information
Description
Access to Information
Release overview
Use the Release Definition for the following
information:
1 Go to http://www.info.teradata.com/.
• Overview of all of the products in the
release
• Information received too late to be
included in the manuals
• Operating systems and Teradata
Database versions that are certified to
work with each product
• Version numbers of each product and
the documentation for each product
• Information about available training
and the support center
3 Type 2029 in the Publication Product ID box.
Late information
2 Click General Search under Online Publications.
4 Click Search.
5 Select the appropriate Release Definition from
the search results.
5
Preface
Type of Information
Description
Access to Information
Additional product
information
Use the Teradata Information Products web
site to view or download specific manuals
that supply related or additional
information to this manual.
2 Click Data Warehousing under Online
Publications, Browse by Category.
3 Do one of the following:
• For a list of Teradata Tools and Utilities
documents, click Teradata Tools and Utilities,
and then select an item under Releases or
Products.
• Select a link to any of the data warehousing
publications categories listed.
Specific books related to Teradata WA are as follows:
• Teradata Dynamic Workload Manager User Guide
B035-2513
• Teradata Tools and Utilities Installation Guide for
Microsoft Windows
B035-2407
• Database Administration
B035-1093
• SQL Data Definition Language
B035-1144
• Utilities: Volume 1 (A-K)
B035-1102
CD-ROM images
Ordering
information for
manuals
Access a link to a downloadable CD-ROM
image of all customer documentation for
this release. Customers are authorized to
create CD-ROMs for their use from this
image.
Use the Teradata Information Products web
site to order printed versions of manuals.
2 Click Data Warehousing under Online
Publications, Browse by Category.
3 Click CD-ROM Images.
2 Click How to Order under Print & CD
Publications.
3 Follow the ordering instructions.
General information
about Teradata
The Teradata home page provides links to
numerous sources of information about
Teradata. Links include:
1 Go to Teradata.com.
2 Select a link.
• Executive reports, case studies of
customer experiences with Teradata,
and thought leadership
• Technical information, solutions, and
expert advice
• Press releases, mentions, and media
resources
6
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Supported Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Changes to This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Chapter 1:
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
What Is Teradata Workload Analyzer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
How Teradata WA Works With Teradata Active System Management . . . . . . . . . . . . . . . . .
Viewpoint Workload Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewpoint Workload Monitor and Workload Health . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Teradata Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
16
17
17
An Overview of Workload Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 2:
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Installation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Required Database Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Required Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Before You Start Teradata WA: Setting Up the TDWM Database Objects . . . . . . . . . . . . . . . 20
Before You Start Teradata WA: Enabling TASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Workload Management Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What To Do About Large Volumes of DBQL Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing the Error Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
21
22
22
Starting Teradata WA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Login and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Connecting to the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7
Table of Contents
Adding Initial Workload Periods for PSA Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Configuring Application Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Getting to Know the Teradata WA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Online Help for Teradata Workload Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Using the Navigation Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Displaying Information About Teradata Workload Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . .33
Chapter 3:
Converting PDSets to Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
PDSet to Workload Mapping Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
The PDSet to Workload Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Selecting PDSets for Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Viewing Priority Scheduler Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Displaying Logs of Conversion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Converting Priority Scheduler Settings to Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Defining SLGs for Converted PDSets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Chapter 4:
Analyzing New Workloads to Meet SLGs . . . . . . . . . . . . . . . . . . . . . . . . . .49
Planning New Workloads for Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Obtaining New Workload Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
First Level Analysis Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
The Steps to Creating New Workload Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . .51
Step 1: Defining An Initial Set of Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Defining DBQL Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Viewing Workloads Using the Candidate Workload Report. . . . . . . . . . . . . . . . . . . . . . . .56
Grouping Unassigned Requests Into a Workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Step 2: Refining and Analyzing Recommended Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Supported Analysis Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Analyzing Workloads Based On “Who” Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Analyzing Workloads Based On “What” Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Step 3: Defining Service Level Goals to Get the Most Out of Reports . . . . . . . . . . . . . . . . . . . .88
How Teradata WA Sets SLGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Service Level Goals and Viewpoint Workload Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Accepting Or Modifying Service-Level Goal Recommendations . . . . . . . . . . . . . . . . . . . .89
Step 4: Mapping Workloads to Allocation Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Category of Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
8
Table of Contents
Subject Area Resource Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Workload-to-Allocation Group Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Defining Enforcement Priorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Step 5: Creating the Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Creating a New Workload For Use from Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Using Deep Drill-Down and Refinement for Workload Analysis . . . . . . . . . . . . . . . . . . . 96
Chapter 5:
Analyzing Existing Workloads to Meet SLGs . . . . . . . . . . . . . . . . . . . 127
Existing Workload Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Further Analysis for Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Enhancing the Existing Workload Analysis Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Starting Existing Workload Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Defining Existing Workload DBQL Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Viewing Workloads Using the Candidate Workload Report. . . . . . . . . . . . . . . . . . . . . . 131
Viewing or Modifying SLGs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Splitting and Merging Workloads for Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Process of Merging Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Splitting Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classifying by Excluded Objects for Splitting and Merging Workloads . . . . . . . . . . . . .
135
135
138
142
Chapter 6:
Viewing or Changing Workload Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Working with Workload Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Working with Workload Classification Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Working with Workload Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Viewing the Active Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Viewing the Candidate Workload Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Viewing Evaluation Order of Candidate Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Chapter 7:
Changes to support TASM 14.10 SLG Responsive Priority
Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
TASM 14.10 — SLES11 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Workload Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9
Table of Contents
Other GUI Changes for TASM SLES11 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Chapter 8:
Recommendation for SLG Tier and Workload Percentage . . .181
The SLG Tier Hints Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
10
List of Figures
Figure 1: Teradata Active System Management and Supporting Components . . . . . . . . . . . 16
Figure 2: Paths to Creating a Workload Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 3: Example of workload and its distinct value counts . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 4: Candidate Workloads Tree in left pane of window . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 5: About Teradata Workload Analyzer dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 6: Candidate Workload Report displays CPU, IO, and Query Volume statistics . . . . 56
Figure 7: Candidate Workload Report window displaying unassigned requests . . . . . . . . . . 57
Figure 8: Example of report with query band name displayed . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 9: Example of Distribution Parameters with ten buckets . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 10: Equal-widths histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 11: Equal-height histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 12: Distribution report after rounding up the widths of buckets for data with a large
range of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 13: Distribution report after rounding up the widths of buckets for data with a small
range of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 14: Overview of deep drill-down analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 15: Workload A with classification Account =A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 16: Workload A and Workload A2 with CPU distribution division . . . . . . . . . . . . . 100
Figure 17: Unassigned elements after classification is added to existing workload . . . . . . . 101
Figure 18: Distribution of top 10 workloads represented as a percentage of CPU processing
when more than 250 workloads are represented after PSA migration. . . . . . . . . . . . . . . . . . 102
Figure 19: Candidate Workload Report for Existing Workloads . . . . . . . . . . . . . . . . . . . . . . 132
Figure 20: Example of two workloads merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Figure 21: Split workload with excluded and included objects. . . . . . . . . . . . . . . . . . . . . . . . 143
Figure 22: Classification tab for original workload after a split . . . . . . . . . . . . . . . . . . . . . . . 143
Figure 23: Classification tab for split workload with excluded and included objects . . . . . . 144
Figure 24: Classification tab for merged workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Figure 25: Add Local Exception Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Figure 26: Sample Exception Apply Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Figure 27: Existing Workload Analysis Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figure 28: SLG Tier Workload Method Hints Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
11
List of Figures
12
List of Tables
Table 1: Connect to Teradata Database dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Table 2: Connect to Teradata Database dialog box Advanced Options. . . . . . . . . . . . . . . . . . 24
Table 3: Define Periods (Operating Environments) dialog box . . . . . . . . . . . . . . . . . . . . . . . . 26
Table 4: Teradata WA Menus and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 5: Define Periods dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 6: Comparison of Granularity Levels and Classification Criteria. . . . . . . . . . . . . . . . . . 50
Table 7: Displayed Columns in the Candidate Workload Report - “who” classifications . . . 57
Table 8: Supported analysis parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 9: Workloads Report shortcut menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 10: Columns in the Analyze Workload report - “what” classification. . . . . . . . . . . . . . 80
Table 11: SLG Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Table 12: Default AG and RP Weights for Priority based on Category of Work . . . . . . . . . . 91
Table 13: Default Mapping of Enforcement Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Table 14: Mapping options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Table 15: Displayed Columns in the Workload report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Table 16: SLG Recommendations window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Table 17: Workload Attribute descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Table 18: Classification Options for Criteria #2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Table 19: Add Local Exception Fields/Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Table 20: Exception Criteria Fields/Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Table 21: Exception Action Fields/Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Table 22: Examples of workloads and evaluation order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Table 23: Default TWA Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
13
List of Tables
14
CHAPTER 1
Introduction
This introduction explains the basic concepts involved with Teradata Workload Analyzer:
•
What Is Teradata Workload Analyzer?
•
How Teradata WA Works With Teradata Active System Management
•
An Overview of Workload Analysis
What Is Teradata Workload Analyzer?
Teradata Workload Analyzer (Teradata WA) helps Database Administrators identify classes of
queries (workloads) and provides recommendations on workload definitions and operating
rules to ensure that database performance meets Service Level Goals (SLG). Through the use
of various reports and graphical displays, Teradata WA makes it easier for administrators to
effectively manage distribution of resources. The more control administrators have over
resource allocation, the more they can ensure satisfactory response times for critical queries.
Teradata WA supports the conversion of existing Priority Scheduler Definitions (PDSets) into
new workloads. A PDSet is the collection of data, including the resource partition, allocation
group, period type, and other definitions that control how the Priority Scheduler manages
and schedules session execution. This is helpful for users that have tuned their Priority
Scheduler settings for their specific workloads.
Teradata WA provides three major areas of guidance:
•
Recommending workload group definitions. The DBA guides these based on business
knowledge and Analyzer-assisted based on existing workload mix and characteristics
•
Recommending appropriate workload goals
•
Recommending workload to AG mapping plus priority scheduler weights
How Teradata WA Works With Teradata Active
System Management
Teradata Active System Management (Teradata ASM) is a set of products, including system
tables and logs, that interact with each other and a common data source. It facilitates
automation in the following four key areas of system management:
•
Workload Management
15
Chapter 1: Introduction
How Teradata WA Works With Teradata Active System Management
•
Performance Tuning
•
Capacity Planning
•
Performance Monitoring
Teradata ASM helps manage the system automatically and reduces the effort required by
DBAs, application developers, and support personnel. With careful planning, Teradata ASM
can improve and optimize your workload management and performance. It can also improve
response times and ensure more consistent response times for critical work.
Some of the products that make up the Teradata ASM solution include Viewpoint Workload
Monitor/Health, Viewpoint Workload Designer, and Teradata Workload Analyzer.
These components are graphically displayed in Figure 1.
Figure 1: Teradata Active System Management and Supporting Components
9LHZSRLQW:RUNORDG'HVLJQHU
7HUDGDWD
:RUNORDG
$QDO\]HU
5XOHVEDVHGRQ7KURWWOHV)LOWHUV
DQG:RUNORDG'HILQLWLRQV
9LHZSRLQW:RUNORDG0RQLWRU
7HUDGDWD
'DWDEDVH
3URYLGHV
'%4XHU\/RJ
'%4/
7':0'%
:RUNORDG/RJ
5HJXODWRU
:RUNORDG+HDOWK
30$3,
'
Related Topics
•
Viewpoint Workload Designer
•
Viewpoint Workload Monitor and Workload Health
•
Teradata Database
Viewpoint Workload Designer
Viewpoint Workload Designer supports detailed creation and management of workload
definitions. Workload definitions are sets of rules that pertain to and describe a class of queries
for the purpose of ensuring appropriate operating resource allocations to them based on
business considerations. These rules apply filters, classification, and throttles and determine
exception processing for workload queries. For more guided definitions of workloads and
service levels, after first defining operating rules through use of Teradata WA, use Viewpoint
Workload Designer to refine them.
Viewpoint Workload Designer provides a simpler way of defining many of the settings
previously controlled with Priority Scheduler Administrator (PSA), which was discontinued
with Release 13.10. TWA can migrate PDSets saved in the DBCMngr database by customers
using earlier PSA releases.
16
Viewpoint Workload Monitor and Workload Health
Viewpoint Workload Monitor provides a view of current and recent historical workload
status. Workload Health provides the current workload status.
Teradata Database
A component of the Teradata Database called the Regulator dynamically executes to fulfill the
workload operating rules as defined with the Workload Administrator. Requests submitted to
the system are classified into the appropriate workload and managed against that workload’s
operating rules, such as throttling, resource priorities, and exception management.
In addition, the Regulator monitors queries as they run to check for exception conditions, and
then handles them according the rules defined in the workload definition configuration
tables.
A separate database called TDWM is required for Teradata Workload Analyzer. The database
contains tables for storing workload definitions and related data. A Database Initialization
Program (DIP) script is used to install the TDWM database. For information about using
Teradata DIP scripts, see Utilities: Volume 1 (A-K) (B035-1102).
The workload analysis process consists of the following steps:
1
The user may optionally migrate existing priority scheduler definitions (PDSets1 created
using PSA release 13.00 or earlier), to automatically create workload definitions with
existing priority scheduler settings. (PSA has been discontinued for TMGR release 13.10.)
If users choose not to migrate existing settings, they can instead choose to define up to 250
workload definitions from scratch. In so doing, users first collect query log information
for the existing workload mix. Then they specify the dimensions to analyze and group
queries against to form candidate workloads (account-based, application-based, and
existing PDSets) and the date and time range over which to analyze the previously
collected query log data.
2
Using this input, Teradata WA recommends candidate workload definitions based on
analysis of Priority Scheduler settings and/or Database Query Log data.
3
With the DBQL analysis path, the user can further refine the candidate workload
definition and the queries in which it contains by either merging with another candidate
workload or splitting the candidate workload into two or more separate candidate
workloads to aid with accounting granularity or workload control. (For example, tactical
queries need higher priority and therefore are split out from the “parent” candidate
workload.) Next, users creating workload definitions from scratch (not for users migrating
from existing priority scheduler settings) are guided through mapping workload
definitions to priority scheduler allocation groups and allocation group weights. Those
1. A PDSet is a collection of data, including a resource partition, performance group, allocation group,
performance period type, and other definitions controlling how the Priority Scheduler manages and
schedules session execution.
17
settings are guided to minimize necessary DBA involvement, though the DBA has the
“advanced” option to refine those settings according to the administrator’s preference.
Note: A workload definition is mapped one-to-one to a priority scheduler performance
group (PG). The priority scheduler for Teradata Release 13.10 allows 250 PGs to be
defined. Four of these are reserved to be the standard PGs (R, H, M, and L) in the default
resource partition. That leaves 246 PGs for use by Teradata DWM.
4
After the user has satisfactorily fine-tuned the candidate workload definition, the user sets
service-level goals, optionally guided by Teradata WA. For example, the user might request
recommendations based on actual response times achieved at a particular service-level
percent, or other factors.
These paths are graphically displayed in Figure 2.
Figure 2: Paths to Creating a Workload Rule Set
Two Paths to Creating a Workload Rule Set
Path 1: Migrating Your Current
Priority Scheduler Settings
Path 2: Generating Statistics from
Your DBQL Data
Load Priority Scheduler
and DBQL Data
Load DBQL Data
Workload Analyzer converts
PD Set settings to TASM
workload settings
Auto-generate or create
workloads by using unassigned
Accounts/Applications/Users
Workload Analyzer recommends
Service Level Goals
Workload Analyzer recommends
Service Level Goals
Save Workload Rule Set
User modifies mapping of
workloads to
Allocation Groups
Save Workload Rule Set
2514E004
18
CHAPTER 2
Getting Started
This section explains setup, configuration, and startup of Teradata WA. It includes the
following:
•
Installation Requirements
•
Before You Start Teradata WA: Setting Up the TDWM Database Objects
•
Before You Start Teradata WA: Enabling TASM
•
Viewing the Error Log
•
Starting Teradata WA
•
Login and Configuration
•
Getting to Know the Teradata WA Interface
•
Using the Navigation Help
•
Displaying Information About Teradata Workload Analyzer
Installation Requirements
This section describes software requirements for Teradata Workload Analyzer (Teradata WA).
For detailed information about installing Teradata WA, see Teradata Tools and Utilities
Installation Guide for Microsoft Windows (B035-2407).
Note: Teradata WA 14.10 is not compatible with Teradata Database versions earlier than
13.10.
Required Database Permissions
Important! To work with Teradata WA, the user must be granted privileges to execute macros
and stored procedures in the database TDWM and the DBQL table.
Note: If the “External DBQL” log option is selected for PSA migration/New workload
recommendations, the GRANT option for SELECT on DUMP DBQL tables must be given to
TDWM. Do this by logging on to the system as DBC and granting SELECT permission to
TDWM on DBQL tables from the External DBQL database.
Note: To access external databases successfully, there must be at least three DBQL tables in the
external database for analysis, such as DBLogtbl, DBQLSummaryTbl, and DBQLObjtbl or
corresponding *_HST tables (a PS setup). The DBQLObjtbl (or corresponding *_HST table)
is necessary for Teradata WA 14.10 to perform analysis on data objects (‘Where’ classification
parameters).
19
Chapter 2: Getting Started
Before You Start Teradata WA: Setting Up the TDWM Database Objects
Required Software
You must have the following software installed on your system:
•
Teradata Database 14.10, 14.0, or 13.10 running on one of these operating systems:
•
Linux
•
Windows® Server 2003
Note: Teradata WA supports access to a custom database called TDWM, which stores
workload definitions and related data.
Teradata WA works in combination with Viewpoint Workload Designer in dynamically
managing workloads for Teradata Database 14.10. For Teradata Database 13.x, however,
Teradata WA 14.10 provides menu-option access to Teradata Dynamic Workload Manager
(TDWM) 12.00 or 13.00 respectively. For more information about the TDWM database
and instructions for using TDWM 12.00 or 13.00, see Database Administration
(B035-1093), and Teradata Dynamic Workload Manager User Guide (B035-2513), for the
appropriate release.
•
Teradata Call-Level Interface version 2 (CLIv2) release 14.10
•
TDICU 14.10
•
TeraGSS 14.10
Note: These are CLIv2 dependencies.
Before You Start Teradata WA: Setting Up the
TDWM Database Objects
In releases prior to TTU14.0, the DIP script (DIPTDWM - TDWM Configuration) set up the
TDWM database objects.
Starting with TTU14.0, the DIP script (DIPTDWM - TDWM Configuration) sets up the
TDWM tables, but TWA itself handles setting up the required objects (procedures and
macros) for client operations.
To setup the TWA objects
1
Connect to the TD14.10 Database using the TWA application.
While connecting to the database, the TWA application checks whether the required TWA
objects exist in the TDWM database or not. If they do not exist, TWA displays a prompt.
20
2
Do one of the following:
•
Click Yes to create objects for TWA database operations.
•
Click No to connect to the database without creating objects.
There is also an option to setup the TWA objects at any time by clicking Tools > twa dbs setup.
The Viewpoint TDWM data collection task must be configured to display Workload Monitor
and Workload Health.
Enabling the advanced features of Teradata Active Systems Management (TASM) in an
environment requires establishment of the operating rules and goals described in the
following subsections.
Creating Workload Management Rules
Teradata WA provides the ability to analyze current Teradata Database usage and recommend
workload management rules appropriate for the system.
Create these rules using one of the following methods:
•
Saving the PDSet to the database for migration
•
To enable detail or summary logging for a specific user or account
Saving the PDSet to the database for migration
Use this method if the optimal priority scheduler settings have already been created for the
workload.
Note: Skip this procedure if Priority Scheduler Administrator (PSA) is already used to
manage your priority scheduler settings.
To save existing Priority Scheduler settings
1
Create a PDSet that contains your Priority Scheduler settings.
2
If more than one set of priority scheduler settings is used (for example, one configuration
during the day and another at night), then create PDSets for the time that each priority
scheduler configuration is active.
21
TWA migrates PDsets currently available in the DBCMngr database.
Capturing the DBQL Query Log
Use this second method if your site uses the default priority scheduler settings. This method
requires logging query activity to DBQL for the period of time that represents a typical
workload (for example, one week).
Note: Skip this procedure if DBQL data is already collected for your workloads.
To enable detail or summary logging for a specific user or account
Teradata WA analyzes both the DBQL detail and summary tables. The detail table contains
one row for each query submitted. The summary table is more efficient: it is updated at
periodic intervals with a count of the number of queries submitted by each user account.
✔ To enable detail logging, enter one of these commands at a command console:
BEGIN QUERY LOGGING ON USER1, USER2, USER3;
BEGIN QUERY LOGGING ON ACCOUNT = (‘ACCT1’, ‘ACCT2’, ‘ACCT3’);
✔ To enable summary logging, enter one of these commands:
BEGIN QUERY LOGGING LIMIT THRESHOLD = 3600 ON USER1, USER2;
BEGIN QUERY LOGGING LIMIT THRESHOLD = 3600 ON ACCOUNT = (‘ACCT1’);
✔ To disable detail or summary logging, use one of these commands:
END QUERY LOGGING ON USER1, USER2, USER3;
END QUERY LOGGING ON ACCOUNT = (‘ACCT1’, ‘ACCT2’, ‘ACCT3’);
✔ TWA also uses data from the DBQL Step Table, if available, for analysis on estimated
processing time. The syntax for step data looks something like this:
BEGIN QUERY LOGGING WITH STEPINFO ON USER1;
Note: This turns on both detail and step logging for “user1” — there is no syntax for
turning on only stepinfo.
For assistance with DBQL syntax and usage, see SQL Data Definition Language (B035-1144),
and Database Administration (B035-1093).
What To Do About Large Volumes of DBQL Data
If the DBQL table contains large volumes of data, this may cause very long query execution
times or a shortage of spool space while using Teradata WA. The recommended solution to
this is to implement DBQL maintenance tables using Teradata Professional Services group
guidelines. For information on recommended DBQL maintenance tables, see Database
Administration (B035-1093) for 14.10.
Viewing the Error Log
Teradata Workload Analyzer logs low level information useful for Global Support Center
(GSC) operations in the TWA.log file located in this directory:
Drive:\Documents and Settings\user\My Documents\Teradata\DBM Logs\
22
Start Teradata WA from the Windows Start menu.
To start Teradata WA
✔ From the Start menu, point to Programs, and click Teradata Workload Analyzer.
The Teradata Workload Analyzer window opens.
To exit Teradata WA
✔ From the menu bar of the Teradata WA main window, select File > Exit.
This section describes connecting to the Teradata Database and defining initial settings for the
Teradata WA application.
Connecting to the Database
Before working with Teradata WA, a connection to the Teradata Database as user tdwm must
be established. No local mode is available.
Note: User tdwm must be created before continuing. Create this user by running a DIP script.
For more information about DIP scripts, see Utilities: Volume 1 (A-K) (B035-1102).
To connect to the Teradata Database as user tdwm
1
Open the Connect to Teradata Database dialog box by doing one of the following:
on the Teradata Workload Analyzer window toolbar.
•
Click
•
Select File > Connect.
•
Press Ctrl+L.
23
2
In the Connect to Teradata Database dialog box, enter the database connection parameters.
See Table 1.
Table 1: Connect to Teradata Database dialog box
Option
Description
System (DBS) Name
Name of the database to connect to; Teradata WA uses this to
store workload definitions and related data.
User Name
Teradata WA requires the user to log on as user tdwm. The name
in this field cannot be edited.
Password
Password associated with the user tdwm.
Note: The default password for this user is tdwmadmin. To
change this password, use the MODIFY USER statement. For
information about using this statement, see Database
Administration (B035-1093).
Session Character Set
This option is not available. A DIP script creates a default
character session set [ASCII for standard, KAJISJIS_0S for Kanjienabled systems (Japanese)].
By default, a UTF-16 character set is displayed.
For more information about DIP scripts, see Utilities: Volume 1
(A-K) (B035-1102).
3
[Optional] Click More to reveal advanced login options. See Table 2.
Table 2: Connect to Teradata Database dialog box Advanced Options
24
Option
Description
Authentication Mechanism
Select the authentication mechanism value in the list box.
Authentication Parameter
Type the appropriate authentication parameter for the selected
authentication mechanism.
Table 2: Connect to Teradata Database dialog box Advanced Options (continued)
4
Option
Description
Default Database
Select the default database used, if any.
Account String
Select the account string, if any.
Click OK.
When connected, the Teradata Workload Analyzer window displays the following:
•
In the lower left corner of the window: Ready
•
In the lower right corner of the window: Logged on to database_name as user_name.
To disconnect from the database
✔ Disconnect from the database by doing one of the following:
on the Teradata Workload Analyzer window toolbar.
•
Click
•
Click File > Disconnect.
•
Press CTRL+G.
Adding Initial Workload Periods for PSA Migration
Before PSA migration, system periods must be set up to associate with the workloads.
Defining multiple system periods allows the system to handle workloads differently depending
on the time of day, day of the month, and so on. In addition, allocation groups and resource
partitions that are defined in Priority Scheduler Administrator or Teradata Dynamic
Workload Manager can be associated with the workload periods.
There are three options for defining system periods:
•
Import system periods from any rule set by clicking Import From Ruleset
•
Import system periods from a .pds file by clicking Import From File
•
Create a new system period by clicking Add Period
To add initial workload periods for PSA migration
1
Open the Define Periods (Operating Environments) dialog box. You can do this in one of
the following ways:
on the Workload Analyzer toolbar.
•
Click
•
Click Tools > Define System Periods.
The Define Periods (Operating Environments) dialog box appears.
25
Table 3 describes the options for the Define Periods (Operating Environments) dialog box.
Table 3: Define Periods (Operating Environments) dialog box
Option
Description
Import From Ruleset
Imports system periods from an existing rule set.
Import From File
Imports system periods from a file.
Save To File
Saves system periods to a .pds file.
Periods
Displays available system periods.
Description
Displays descriptions of available system periods.
Add Period
Adds a new system period to the Periods list.
Delete Period
Deletes the selected system period from the Periods list.
Everyday
Defines this period for every day usage.
This is the default setting.
Day of Week
26
Defines this period for usage on specific days of every week. If
using this option, click the check box for each day of the week to
be included.
Table 3: Define Periods (Operating Environments) dialog box (continued)
Option
Description
Month/Day
Defines this period for usage on specific months of the year and
days of the month. Click the Months button to display the Select
Months dialog box; under Select Months, click the check box for
each month to be included and click OK. Then click the Days
button to display the Select Days dialog box; under Select Days,
click the check box for each day to be included and click OK.
Notice that the Months box under the Date/Time tab shows the
numerals for the months or days selected. If there is a range of
days or months, these may be separated by a comma or a hyphen
as appropriate.
24 Hours
Defines this period for usage 24 hours at a time. To define the
period for less than 24 hours at a time, de-select this check box.
The default is “selected”.
From
Defines the period starting time, where HH can be any hour
from 0 (12:00 A.M.) to 23 (11:00 P.M.) and MM can be any
number of minutes from 0 to 59. The default start time is 0:00.
To
Defines the period ending time in HH:MM format, where HH
can be any hour from 0 (12:00 A.M.) to 23 (11:00 P.M.) and MM
can be any number of minutes from 0 to 59. The default end
time is 23:59.
Wrap Around Midnight to Next
Day
Defines a range in time that spans midnight for system periods
to be in effect.
When the numeric value of the time specified in the From text
box is greater than the numeric value of the time specified in the
To text box, two conceptual time segments are available:
• Start at midnight until the time specified in the To text box.
• Start from the time specified in the From text box to
midnight.
Accept
2
Accepts the changes made to the Time box.
To import the periods from a rule set, do the following:
a
Click Import From Rule Set.
The Select Rule Set dialog box appears.
27
3
b
Active Rule Set displays the currently active rule set.
c
Click on a row in the Existing Rule Sets list to select a different rule set, or click Use
Active Rule Set to continue using the active rule set.
d
Click OK to save the selection.
To import the periods from a file, do the following:
a
Click Import From File.
The standard Open file dialog appears.
4
b
Select the appropriate .pds file.
c
Click OK.
To create a new system period, do the following:
a
Click Add Period.
The Add Period dialog box appears.
28
b
In the Period Name text box, type a name for the new period.
c
In the Description text box, type a brief description of the period.
d
Click OK.
e
The new period name displays in the Periods list.
f
Clear the Everyday check box and define the days and months that this workload
period should be in effect.
g
Clear the 24 Hours check box to define the hours that this workload period should be
in effect.
h
Click the Date/Time tab and define the days and times that this workload period should
be in effect.
i
After completing these changes as appropriate, click Accept.
j
Click Save to File.
The new system period is saved to a .pds file.
Configuring Application Options
This section discusses the setting of Teradata WA options, allowing for configuration of
application settings.
The Show Distinct Count option allows the display of the number of distinct value counts for
all possible correlation parameters. It also allows the display of total available ranges for
distribution parameters.
This feature provides an automated, intermediate analysis step to identify distinct value
counts within all possible correlation parameters as well as a “heterogeneous” identification
metric for the workload in general.
For example, with respect to the distinct value counts, a workload could display the following
characteristics.
Figure 3: Example of workload and its distinct value counts
Example of a workload and its distinct
value counts
User Name (24)
Application (1)
Account Name (1)
Client Addresses (2)
Queryband
Function (3)
Urgency (1)
AggLevel (8)
Estimated Processing Time (0 to 1000 seconds)
AMP Count (0 to 1)
2514A012
In Figure 3, the DBA benefits from the knowledge that there is only one distinct Application
or Account, which run at the same urgency, so the effort in identifying a correlation against a
different Application, Account, or other urgency values would be a waste of time.
The opportunity for correlation does exist for Users (24), Function (3), and Agglevel (8), so
those options could be further analyzed in a trial and error method. The same process is
applicable for selecting a distribution parameter because the Estimated Process Time has a
large range, and drill-down required for analysis and classification.
The Show Distinct Count option is useful in avoiding unnecessary trial and error analysis by
providing a direct analysis of distinct value counts in a workload. The distinct value counts are
updated after each level of analysis. See “Using Deep Drill-Down and Refinement for
Workload Analysis” on page 96 for more information.
29
To define Teradata WA options
1
From the Tools menu, select Options.
The Options dialog box appears.
2
Fill in the options as described in the table.
Option
Contains
Show Distinct Count
Select this check box to display the distinct value counts
for workload correlation parameters and the total
available range for distribution parameters on the
Analyze Workload tab.
Workload Prefix
The default characters used as the prefix in the workload
definition name. The default is WD. Type a new value if
appropriate.
Note: Using long prefixes can result in long workload
definition names that might not be displayed properly in
Viewpoint Workload reports. Keep prefixes as short as
practical.
3
Click OK to save the changes, or Cancel to discard them and start over.
The Teradata WA user interface provides options for developing workloads and allocating
service level goals. Table 4 lists the menu items of the Teradata WA interface.
30
Table 4: Teradata WA Menus and Options
Menu
Option
Used to...
For more information, see...
File
Connect
Connects to the Teradata Database. Displays “To connect to the Teradata
the Connect dialog box requiring logon
Database as user tdwm” on
information.
page 23
Alternatively, click
on the toolbar, or
press Ctrl+L for this option.
Disconnect
Disconnects from the Teradata Database.
on the toolbar, or
press Ctrl+G for this option.
View
Exit
Exits from Teradata Workload Analyzer.
“To exit Teradata WA” on page 23
Toolbar
Toggles the status of toolbar visibility.
—
Status Bar
Toggles the status of status bar visibility.
—
Active Rule Set
Displays the active workload rule set
information.
“Viewing the Active Rule Set” on
page 170
this option.
Navigation Help
Convert PDSets to
Workloads…
on the toolbar for
Displays a checklist of tasks required to
convert PDSets to Workloads.
Analysis
“To disconnect from the
database” on page 25
“Using the Navigation Help” on
page 33
on the toolbar.
Converts PDSet information created using
the Priority Scheduler Administrator into
equivalent workloads.
“PDSet to Workload Mapping
Considerations” on page 35
on the toolbar, or
press Ctrl+D for this option.
New Workload
Recommendations
Generates workload rules.
Existing Workload
Analysis
Starts the analysis of existing workloads.
on the toolbar, or
press Ctrl+L or Ctrl+W for this option.
on the toolbar, or
press Ctrl+E for this option.
“Obtaining New Workload
Recommendations” on page 51
“Existing Workload Analysis” on
page 127
31
Table 4: Teradata WA Menus and Options (continued)
Menu
Option
Used to...
For more information, see...
Tools
Teradata Dynamic
Workload Manager
Starts the Teradata Dynamic Workload
Manager application from Teradata WA for
users running Teradata Database 12.0
through 13.0 only.
Teradata Workload Analyzer User
Guide (B035-2514), Releases
12.00 through 13.00.
this option.
Define System
Periods…
Defines period definitions at the system
level global to all workloads.
this option.
Help
on the toolbar for
“Adding Initial Workload Periods
for PSA Migration” on page 25
on the toolbar for
Options
Specifies application level options.
“Configuring Application
Options” on page 29
Help Contents
Displays a browser window containing
online Help contents and topics.
“Online Help for Teradata
Workload Analyzer” on page 33
this option.
About Teradata
Workload Analyzer
on the toolbar for
Displays the About dialog box that provides
useful information about Teradata WA and
the current database session, including
database version and release numbers.
—
During the process of creating a new workload recommendation, the left pane of the window
lists workload definitions as separate nodes in the Candidate Workloads tree. Additional nodes
appear under each workload definition for attributes and service level goals. (By design, the
Default workload definition does not have service level goals.)
Figure 4: Candidate Workloads Tree in left pane of window
For more information, see:
32
•
“Step 3: Defining Service Level Goals to Get the Most Out of Reports” on page 88
•
“Working with Workload Attributes” on page 147
Online Help for Teradata Workload Analyzer
Note: To toggle display of workloads on and off, from the View menu, click View Workloads.
When you check this menu option (checked is the default), the Teradata WA user interface
displays the Candidate Workloads tree; otherwise, it is not displayed.
Online Help for Teradata Workload Analyzer
Teradata WA online help answers questions about how to use Teradata WA features. Online
help (including context-sensitive help) opens in a browser window. Microsoft Internet
Explorer version 6.0 or later is the recommended browser for viewing online help and contextsensitive help. A browser other than the recommended browser might result in incorrectly
displayed help.
Using the Navigation Help
The Navigation Help guides users through the process of converting PDSets to Workloads.
The Navigation Help provides a checklist of actions to perform. A check mark appears next to
each completed action.
To start Navigation Help
✔ Select View > Navigation Help, or click
on the toolbar.
The Navigation Help menu is automatically displayed when selecting Analysis > Convert
PDSets to Workloads.
Displaying Information About Teradata
Workload Analyzer
To display information about Teradata Workload Analyzer
The About screen provides useful information about Teradata WA and the current database
session, including database version and release numbers.
✔ Select Help > About Teradata Workload Analyzer.
The About dialog appears as shown in Figure 5.
33
Displaying Information About Teradata Workload Analyzer
Figure 5: About Teradata Workload Analyzer dialog
34
CHAPTER 3
Converting PDSets to Workloads
This section describes the process of converting your existing PDSets to workloads. It includes
the following:
•
PDSet to Workload Mapping Considerations
•
The PDSet to Workload Conversion
PDSet to Workload Mapping Considerations
PDSets must meet the following requirements to successfully map to workloads:
•
There must be a one-to-one correlation between workloads and performance groups.
•
Only one performance period is allowed per performance group.
•
One workload is created for each account. However, if the total number of accounts for all
PDSets is 35 or more, one workload is created per performance group.
•
If multiple accounts are available for a workload/performance group, the account names
are OR’d in the classification table, creating multiple rows - one per account.
•
If no associated account is found in DBQL for a performance group, then it is marked
inactive. There is no workload created in this case.
•
The Classify Condition for Acct is AcctName.
•
If an “inactive performance group” is overridden to an “active” one, then the Classify
Condition is: Acct = $PGName (the Priority Group part of the performance group).
Note: If the message “The PSA database is Locked by another user” appears when running
PSA migration, it means that either the PSA database is currently being accessed or that a
previous user of the PSA database exited without freeing the lock. The standard resolution in
this case would be to wait to for the lock to be released. If after a period of time you suspect the
lock is hung, you should determine if it is safe to free the lock manually and then repeat the
operation.
This section describes the process of PDset to workload conversion. This section contains the
following:
•
Selecting PDSets for Conversion
•
Viewing Priority Scheduler Settings
35
Chapter 3: Converting PDSets to Workloads
•
Displaying Logs of Conversion Messages
•
Converting Priority Scheduler Settings to Workloads
•
Defining SLGs for Converted PDSets
Selecting PDSets for Conversion
To select PDSets for conversion
1
on the Workload Analyzer toolbar.
•
Click
•
Select Analysis > Convert PDSets to Workloads.
•
Press Ctrl+D.
If there are no scheduled PDSets available, the Select PDSet(s) dialog box appears.
Teradata WA retrieves any scheduled PDSets.
•
To define a new period, click Define Periods.
The Define Periods (Operating Environments) dialog box appears.
36
The fields and controls on this dialog box are described in the table below.
Table 5: Define Periods dialog box
Option
Description
Import From Ruleset
Imports system periods from an existing rule set.
Import From File
Imports system periods from a file.
Save To File
Saves the system period to a .pds file.
Periods
Displays the available system periods or imported periods from
the rule set or file.
Description
Displays descriptions of the available system periods.
Add Period
Adds a new system period to the Periods list.
Delete Period
Deletes the selected system period from the Periods list.
Everyday
Defines this period for every day usage.
This is the default setting.
Day of Week
Defines this period for usage on specific days of every week. If
using this option, click the check box for each day of the week to
be included.
37
Table 5: Define Periods dialog box (continued)
Option
Description
Month/Day
Defines this period for usage on specific months of the year and
days of the month. Click the Months button to display the Select
Months dialog box; under Select Months, click the check box for
each month to be included and click OK. Then click the Days
button to display the Select Days dialog box; under Select Days,
click the check box for each day to be included and click OK.
Notice that the Months box under the Date/Time tab shows the
numerals for the months or days selected. If there is a range of
days or months, these may be separated by a comma or a hyphen
as appropriate.
24 Hours
Defines this period for usage 24 hours at a time. To define the
period for less than 24 hours at a time, de-select this check box.
The default is “selected”.
From
Defines the period starting time, where HH can be any hour
from 0 (12:00 A.M.) to 23 (11:00 P.M.) and MM can be any
number of minutes from 0 to 59. The default start time is 0:00.
To
Defines the period ending time in HH:MM format, where HH
can be any hour from 0 (12:00 A.M.) to 23 (11:00 P.M.) and MM
can be any number of minutes from 0 to 59. The default end
time is 23:59.
Wrap Around Midnight to Next
Day
Defines a range in time that spans midnight for system periods
to be in effect.
When the numeric value of the time specified in the From text
box is greater than the numeric value of the time specified in the
To text box, two conceptual time segments are available:
• Start at midnight until the time specified in the To text box.
• Start from the time specified in the From text box to
midnight.
Accept
•
Accepts the changes made to the Time box.
To instruct Teradata WA to include active performance groups, click DBQL Inputs in
the Select PDSet(s) dialog box. The date and time range of activity logged in DBQL
can be modified in the Data Collection Interval dialog box.
Note: If the DBQL data has been migrated to another database as described in “What To
Do About Large Volumes of DBQL Data” on page 22, do the following: in the Data
Collection Interval dialog box, select External DBQL as the Log Option, and enter
workdata as the Database name.
38
Teradata WA obtains the performance groups for accounts which had activity during the
defined interval. Otherwise, Teradata WA uses the data dictionary (dbc.users) table to
determine performance groups.
2
Under Available PDSets, click the name of the PDSet to be converted and ensure that:
•
An OpEnv is selected. This is required for conversion.
•
A PDSet has been associated with the Default period.
•
The entire row is selected (indicated by black shading), not just the cell containing the
PDSet name. For example:
39
Teradata WA associates the PDSet with a period in DWM that most closely corresponds to
the performance period defined in the PDSet.
To select multiple PDSets, hold down the Ctrl key and click the names of the PDSets you
want to select from column 1 of the table.
3
4
Under Available PDSets, also select an OpEnv and select or clear the Default check box as
appropriate. Only one PDSet can be associated with the Default period.
•
If the operating environment does not appear in the OpEnv list box, click the Define
Periods button to create additional periods as described in “Adding Initial Workload
Periods for PSA Migration” on page 25.
•
To specify the range of data included to obtain active performance groups, click the
DBQL Inputs button and, in the Data Collection Interval dialog box, change the Date
Range, the Time Window, or both. Click OK when finished.
Repeat this process, as applicable, for each PDSet to be converted. Then click Proceed to
load the detailed parameters for the PDSets.
When DWM has finished retrieving the settings, the Existing PSA Setting tab appears.
By default the Existing PSA Setting tab shows information for all RPs and the associated
periods.
40
Scheduled PDSets
When migrating scheduled PDSets, the operating environments (Periods) will be derived
from the scheduling information in the PDSets. If there are multiple scheduled PDSets and
any of the PDSets contains time of day milestones, an error message will be displayed as a Rule
Set cannot be created from multiple PDSets when any of the PDSets uses time of day (TOD)
milestones.
Viewing Priority Scheduler Settings
To view Priority Scheduler settings
1
Choose from the following:
•
To view information for a specific RP, select the appropriate RP in the RP Name list box
of the Existing PSA Setting tab.
•
To change the associated period, select an appropriate period name in the OpEnv list
box.
•
To display or modify the details for the selected period, click OpEnv Details.
When the appropriate RP appears, notice that the tab displays the following information
from the original PDSet.
Option
Description
RP Name
The RP name associated with the PDSet
PG Name
The performance group in the corresponding resource
partition
PG Status
The performance group status as active (the PG currently has
active processes) or inactive (the PG currently has no
processes active). To change the status, click or clear the check
box as appropriate.
Account
The account string associated with the RP and PG
Milestone
The performance period type associated with the milestone in
the PDSet
Allocation Group
The allocation group associated with each performance
period. Multiple columns appear for each performance
period, starting with PerformancePeriod1
Milestone Value
The milestone limit defined for the performance period in the
PDSet
AG Weights
Displays allocation group weights for the resource partition in
the Existing Priority Scheduler Weights dialog box
Convert
Displays the converted PDSets as workload definitions in the
Migrated TASM Settings dialog box
41
Option
Description
Convert by Account
Converts the PDSets as workload definitions based on
Accounts.
Note: If the number of workloads exceeds the maximum
when this option is selected, an error message (62218)
prompts you to exclude some accounts from the conversion or
to try to create the workloads by PG instead.
Convert by Performance Group
Converts the PDSets as workload definitions based on
Performance Groups.
Note: If the number of workloads exceeds the maximum
when this option is selected, an error message (62218)
prompts you to exclude some PGs from the conversion.
Close
2
Closes the dialog box.
To see allocation group weights for the resource partition, click AG Weights.
The Existing Priority Scheduler Weights dialog box appears displaying:
42
•
PDSet name
•
OpEnv name
•
Resource partition name
•
Resource partition weight
•
Allocation group name
3
•
Allocation group weight
•
Relative weight
When you are finished reviewing the settings, click Close.
Displaying Logs of Conversion Messages
To display a log of conversion messages
1
On the Existing PSA Setting or Migrated TASM Settings tab, click Show Log to view a report
of scheduled PDSets and related periods.
The log from the Existing PSA Setting tab shows the number of PDSets selected, the type
of migration, and any errors from the merging and migration process.
The log from the Migrated TASM Settings tab lists the PDSets that have been converted to
workloads and any errors that have occurred during that process.
2
Choose from the following:
•
Click Save to save the log to a file.
•
Click Print to send the log to the printer.
•
Click OK to close the window.
Converting Priority Scheduler Settings to Workloads
To convert Priority Scheduler settings to workloads
1
In the Existing PSA Setting dialog box, click Convert.
The Migrated TASM Settings tab appears.
43
Notice that the dialog box provides the following new workload definition information:
•
RP Weight
•
AG Name
•
Enforcement Priority
•
AG Weight
•
Relative Weight
•
Previous Relative
•
Workload Name
•
Classify Criteria
By default, the conversion maps the PDSet “as is.” However, if you select Simplified
Structure, DWM maps the PDSet such that the default RP is not used for requests even if
the original PDSet did so. Instead, DWM creates a new RP for the work from the Default
RP, reserving the Default RP for system work. A tactical partition is created for shortrunning, high-priority tactical queries, and the Standard partition runs the remaining
work.
2
After selecting either Remap As Is or Simplified Structure, click Continue to complete the
conversion.
3
Click Cancel to exit the dialog box.
4
In the Parameters window, click View CPU Distribution.
This prompts Teradata WA to group accounts into workloads and displays the PSA to DWM
Conversion - CPU Distribution dialog box.
44
5
The fields and controls on this dialog box are described in the table below.
Option
Description
Log Option
Select the appropriate log from these options:
• DBQL (default)
• External DBQL
External DBQL contains DBQL data which has been
copied to a database other than DBC. Its table schema
can be identical to DBQL, but for improved
performance Teradata recommends that DBQL data
be copied to a history database defined according to
Professional Services guidelines. See Database
Database
The database being analyzed.
Date Range
Enter the starting and ending dates of the range of the
data collected. The displayed date format depends on the
regional settings of the PC. To select a date from a
calendar pop-up window, click the drop-down arrow.
The default start date is a month prior to the current
system date; the default end date is the current system
date.
45
Option
Description
Time Window
Enter the starting and ending times of the range in HH
format, using a 24-hour clock. Alternatively, click the
drop-down arrow to select an hour from the list. The
default Start Hour is 00 (12:00 A.M.) and the default End
Hour is 23 (11:00 P.M.).
Note: Teradata WA includes all of the specified End
Hour in its analysis. For example, End Hour 23 means
analyze DBQL data up to and including 23:59:59.99.
6
OpEnv
Select the period. Click the ... button to populate the list
with all available periods.The default is Always.
Top N Value
This value indicates the number of the most resourceintensive workloads to analyze. For example, 3 analyzes
the three most resource-intensive workloads running (10
is the default).
View CPU Distribution
Calculates CPU distribution of workloads.
Save Rule Set
Saves the current rule set.
Select Rule Set > Calculate All WD SLGs.
A progress bar appears while Teradata WA determines the service level goal
recommendations. These appear in the SLG Recommendations pane.
46
Defining SLGs for Converted PDSets
To define service level goals for converted PDSets
1
In the SLG Recommendations dialog box, view the default parameters and resulting service
level recommendations, along with the resulting chart.
2
Set the options as described in the table below.
Option
Description
SLG Parameters
Displays the service parameters that can be viewed or modified
to generate Teradata WA SLG recommendations. Click a service
parameter in the list or accept the default (Response Time) as
appropriate.
When a listed parameter is selected:
• that parameter appears as the horizontal axis of the chart
• after selecting the Set Manual option, the value of all
parameters can be edited in the SLG Recommendations
window
Changing the setting prompts Teradata WA to update the graph
immediately.
OpEnv
Displays the available operating environments. Click an
operating environment in the list box or accept Always as
appropriate.
immediately.
Set Manually
Click this check box (cleared by default) to modify the
recommended service levels.
Recommended SLG
When setting levels manually, you can change the selected
service parameter’s recommended value (shown highlighted in
white). No other values are available for edited (shown shaded).
Arrival rate, Response Time, Throughput and Service Percent
appear. The response time goal shown is the value that would
satisfy a 80% goal.
3
Recommend on current
Service percent
Displays the current performance baseline that Teradata WA
automatically uses for determining service level
recommendations. You can adjust this as appropriate.
Factor by
Modifies the SLG parameter, with a factor of 1 being the same
as today, 0.1 being 10 times faster than today, 10.0 being 10
times slower than today.
Click Apply.
47
48
CHAPTER 4
Analyzing New Workloads to Meet SLGs
This section describes how to plan, select, and analyze new workloads to meet service level
goals using Teradata WA. It consists of the following:
•
Planning New Workloads for Analysis
•
Obtaining New Workload Recommendations
•
Step 1: Defining An Initial Set of Workloads
•
Step 2: Refining and Analyzing Recommended Workloads
•
Step 3: Defining Service Level Goals to Get the Most Out of Reports
•
Step 4: Mapping Workloads to Allocation Groups
•
Step 5: Creating the Workloads
•
Using Deep Drill-Down and Refinement for Workload Analysis
The keys to developing service level goals and distributing resources adequately to achieve
those goals are:
•
Identifying new candidate workloads
•
Segmenting them into manageable pieces
•
Assigning them appropriate priorities
Teradata WA enables administrators to understand their resource-intensive workloads at a
high level. Instead of identifying workloads on the SQL statement level, Teradata WA defines
them by account or application. This isolates workloads in a way that is more relevant to the
business of the enterprise. Administrators can associate resource demands with “who” is
generating the work or by “what” work is being done. When Database Administrators know
these critical factors, they can make informed choices about allocating resources in the best
interests of the organization.
For example, a mission-critical application that is not resource-intensive might be a single
workload and a single service-level goal with a high percentage of resources allocated, while
ad-hoc applications can be grouped together and supported at a lower percentage of service.
In addition to identifying workloads from a business perspective, it is important to find a way
to segment the workloads for effective management. If the majority of work is attributable to a
single application, it is nearly impossible to break that work down and distribute resources
across the work according to its priority. In this case, organizing a workload according to
49
Chapter 4: Analyzing New Workloads to Meet SLGs
accounts might be more reasonable. For example, the DBA might identify the user groups,
departments, or divisions performing the work and assign priorities based on the needs of
those groups. These priorities would determine the allocation of resources to them.
More important workloads should receive a greater share of system resources so that they
process before others. In addition, workloads expected to process quickly should be set at a
higher priority, while slower ones should be set at a lower priority.
In this way, administrators use not only a technical but also a business orientation to
determine workload selection when creating new workload recommendations using Teradata
WA.
Teradata WA performs analysis using three fundamental criteria, with each representing a
greater level of granularity:
•
“Who” is requesting the work?
•
“What” are the request’s performance characteristics?
•
“Where” is the request targeted?
“Who” is the account or application that initiated the queries, “what” are performancerelated characteristics of the queries, and “where” is the database against which the queries
run. Based on these criteria, some obvious associations can be made between similar queries
to assign them to the same workloads for the sake of efficiency. However, for best results, look
next at the query components and characteristics at finer levels of detail, to ensure they are
appropriately for greatest optimization.
The data Teradata WA uses to tune workloads for management according to criteria and
granularity level is described in Table 6.
Table 6: Comparison of Granularity Levels and Classification Criteria
Granularity Level
Type of Criteria
Includes
Low
Who
•
•
•
•
•
•
•
•
Medium
Who, What
The Who criteria plus:
Account
Account String
Application
Client IP Address
Client ID for logon
Profile
Username
QueryBand
• Type of statement (SELECT, DDL, DML, or Collect Stats),
individually or in combination
• UtilityType
• AMP usage (one or a fewer at most)
• Minimum and maximum estimated row counts, including final
row counts
• Minimum and maximum estimated CPU time
50
Table 6: Comparison of Granularity Levels and Classification Criteria (continued)
Granularity Level
Type of Criteria
Includes
High
Who, What, Where
The Who and What criteria plus:
•
•
•
•
•
•
•
Databases
Tables
Views
Macros
Stored Procedures
Function
Method
The first level of analysis is performed with the New Workload Recommendation option, using
criteria based on account, user name, application, or profile.
First Level Analysis Features
As part of the analysis process, Teradata WA:
•
Recommends workload definitions based on automated analysis of DBQL using “who,”
“what,” and “where” parameters
•
Merges two or more workload definitions (user-enabled)
•
Splits workload definitions (user-enabled)
•
Recommends appropriate workload service level goals
•
Recommends workload to allocation group (AG) mapping plus priority scheduler weights
The Steps to Creating New Workload Recommendations
The new workload recommendation process involves five major steps:
•
“Step 1: Defining An Initial Set of Workloads” on page 52
Define an initial set of workloads by grouping one or more accounts, users, applications,
or profiles.
•
“Step 2: Refining and Analyzing Recommended Workloads” on page 63 and “Using Deep
Drill-Down and Refinement for Workload Analysis” on page 96
[Optional] Analyze workloads, using one or more deeper levels of analysis to potentially
provide multi-level classifications on additional “who,” “where,” or “what” criteria
parameters.
•
“Step 3: Defining Service Level Goals to Get the Most Out of Reports” on page 88
Recommend service level goals for the workloads.
•
“Step 4: Mapping Workloads to Allocation Groups” on page 90
51
Develop Priority Scheduler Mapping recommendations and weights for each workload
definition.
•
“Step 5: Creating the Workloads” on page 94
Save the analysis results by creating a new workload.
The new workload recommendations process begins with defining the DBQL inputs for
workloads. This is the first level of analysis.
Defining DBQL Inputs
To define DBQL inputs
1
in the Workload Analyzer toolbar.
•
Click
•
Select Analysis > New Workload Recommendations.
•
Press Ctrl+W.
The Define DBQL Inputs dialog box appears.
52
2
Fill in the fields as described in the following table.
Option
Description
Log Option
• DBQL (this is the default)
• External DBQL
Click the ... button to load the database choices into
the selection box, then select the database.
External DBQL contains DBQL data that has been
53
Option
Description
Date Range
In the appropriate boxes, enter the starting date (From)
and ending date (To) of the range of the data collected.
The displayed date format depends on the regional
settings of the PC. To select a date from a calendar popup window, click the drop-down arrow. The default end
date is one day prior to the current system date; the
default start date is one week (7 days) prior to the default
end date.
Time
Select this option to specify a time window of less than 24
hours.
In the appropriate boxes, enter the starting and ending
times of the range in HH:MM:SS format, using a 24hour clock. The default start time is 00:00:00 (12:00
A.M.) and the default end time is 23:59:59 (11:59:59
P.M.).
To select a time that spans midnight, select a start time
greater than the end time from the Time of Day box.
Note: Teradata WA includes all of the specified end time
in its analysis. For example, an end time of 23:59:59
means analyze DBQL data up to and including
23:59:59.99.
Top N Filter
Select this option to filter the returned data.
Top N Value
Enter a value indicating the number of the most
resource-intensive workloads to analyze. For example,
enter 3 to analyze the three most resource-intensive
workloads running (10 is the default).
Note: For better performance, implement an external
historical copy of DBQL data using Professional Services
guidelines and definitions, and use the same external
database for workload analysis.
Filter within Range
Select this option to filter the returned data by days of the
week and times of day. When selected, the Every Day and
24 Hours checkboxes become enabled and selected.
Every Day
When the Filter within Range check box is selected as
described in the previous row of this table, the Every Day
check box becomes enabled and selected. If left in that
condition, returned data will be captured in the database
every day of the week.
Clear the Every Day check box to select specific days of
the week to exclude from data capture.
When the Every Day check box is cleared, all options in
the Day of Week pane are enabled and selected. Clear one
or more of the check boxes for options Sunday, Monday,
Tuesday, Wednesday, Thursday, Friday, and Saturday to
exclude data capture on those days of the week.
54
Option
Description
24 Hours
described earlier in this table, the 24 Hours check box
becomes enabled and selected. If left in that condition,
returned data will be captured in the database 24 hours
per day for each day selected for capture as specified by
the Every Day option.
Clear the 24 Hours check box to specify a time window of
less than 24 hours during which data will be captured.
In the appropriate boxes under Time of Day, enter the
start time (From) and end time (To) in HH:MM:SS
format, using a 24-hour clock. The default start time is
00:00:00 (12:00 A.M.) and the default end time is
23:59:59 (11:59:59 P.M.).
To select a time spanning midnight, specify the start time
as greater than the end time.
23:59:59.99.
Category
Select the appropriate category from these options:
• Account String
Select this option to classify queries based on the
account string of the user submitting the workload;
this is the default.
• Users
username submitting the workload.
• Applications
application that is submitting the workload.
• Profile
profile attached with the user.
3
After specifying the options, click OK. Teradata WA queries the DBQL. The query process
may take several minutes.
The Candidate Workload Report window appears.
55
Figure 6: Candidate Workload Report displays CPU, IO, and Query Volume statistics
The Distribution Charts tab shows the same information in a pie chart with a legend pop-up
window.
Viewing Workloads Using the Candidate Workload Report
The Candidate Workload Report window is divided into the following panels:
•
The right panel displays the Workloads Report. This is a list workloads, the percent of the
CPU used to process them, average estimated processing time, and the normalized CPU
processing time per query.
•
The left panel displays the Candidate Workloads tree showing the names of the workloads.
After each workload analysis, split, or merge, the workloads redisplay with the evaluation
order. See “Viewing Evaluation Order of Candidate Workloads” on page 172 for more
information.
All workloads created during analysis are temporary workloads until they are saved to the
database.
The maximum number of workloads supported is 250. There are five default workloads,
leaving 245 user-defined workloads. Typically the number of workloads will range between 10
56
and 20 for manageability. On systems with a large number of unassigned requests (accounts or
applications, or users), grouping can be used to keep the number of workloads within the
supported range.
Figure 7: Candidate Workload Report window displaying unassigned requests
Table 7 describes the columns in the Candidate Workload report “who” classification.
Table 7: Displayed Columns in the Candidate Workload Report - “who” classifications
Column Name
Description
Account String
The database-related account string for the user
Percent of Total CPU
Percentage of the total CPU time (in seconds) used on all
AMPs by this session
Percent of Total I/O
Percentage of the total number of logical input/output (reads
and writes) issued across all AMPs by this session
Query Count
The number of queries in this workload that completed
during this collection interval
Avg Est Processing Time
The average estimated processing time for this user
Normalized CPU per Query
(Seconds)
The minimum, average, maximum, standard deviation, 95th
percentile and maximum expected CPU time for queries in
this workload. Normalized CPU per Query (Seconds) is the
default distribution parameter.
Min, Avg, StDev, 95th Percentile,
Max
57
Table 7: Displayed Columns in the Candidate Workload Report - “who” classifications (continued)
Column Name
Description
UnNormalized CPU per Query
(Seconds)
percentile and maximum expected UnNormalized CPU time
for queries in this workload.
Max
Response Time (Seconds)
Min, Avg, StDev, Max
Result Row Count
Disk I/O Per Query
CPU To Disk Ratio
Active AMPS
Spool Usage (Bytes)
CPU Skew (Percent)
I/O Skew (Percent)
The minimum, average, standard deviation, and maximum
response time for queries in this workload
result rows returned for this workload
disk I/O’s per query for this workload
CPU/Disk ratio for this workload
number of active AMPs for this workload
spool usage across all VProcs for this workload
AMP CPU skew for this workload
The minimum, average, standard deviation, and maximum of
AMP I/O skew for this workload
Grouping Unassigned Requests Into a Workload
You can group unassigned requests such as accounts, applications, users, or profiles into a new
workload.
To group unassigned requests into a workload
1
From the Unassigned Requests report panel, press Ctrl and click the rows to be grouped
into a workload.
2
Right-click to display shortcut menu.
The options for the Unassigned Requests report shortcut menu are described in the table.
58
3
Option
Submenu option
Description
Add To
New Workload
Select a single row or block of rows from the
Unassigned Requests report and select this
option to create a new workload and add all the
selected unassigned accounts, applications, or
users to the workload.
Existing Workload
Select a single row or block of rows from the
Unassigned Requests report and click this
option to assign these clusters to an already
defined workload.
Auto-Generate
Workloads
Automatically generates single, new workloads
from the rows in the Unassigned Requests
report that contain the “who” criteria.
Add Workload Using
WildCard
Click this option to open the Select WildCard
dialog box to assign these clusters with wild card
filters.
Save Report As
Saves the Unassigned Requests report to a file in
.xml, .txt, or .html format.
Print Report
Prints the Unassigned Requests report.
Show/Hide Details
Hides or displays all unassigned requests under
OTHERS row, in case the Top N value selected is
greater than the N requests found in the
database. If not, this option is unavailable.
Click Add To, then click New Workload.
The Add Workload dialog box appears.
4
From the Add Workload dialog box, complete the options as appropriate for the new
workload. See the following table.
Note: If there are more than 31 user-defined workloads and five internally generated
workload definitions, the Add Workload dialog box becomes unavailable.
59
5
Option
Description
Name
The name of the workload.
Description
A description of the workload.
• Tactical - short queries with a fixed response-time
requirement.
• Priority - important queries that should get extra
resources.
• Normal - normal queries; this is the default.
• Background - low-priority queries with no response
time requirement.
Click OK.
The newly created workload now displays in the Workloads Report section of the Candidate
Workload Report window.
For information on creating individual workloads for each unassigned request row, see
“Creating a Separate New Workload for Each Selected Row” on page 71.
To group unassigned requests into an existing workload
1
From the Unassigned Requests report panel, press Ctrl and click the rows to be grouped
into an existing workload.
2
Right-click to display shortcut menu.
3
Click Add To, then click Existing Workload.
The Select Workload dialog box appears.
60
4
Select the workload you want to add the unassigned requests to. Click OK.
5
The selected unassigned requests are grouped with the existing workload and are removed
from the Unassigned requests report.
To create a separate new workload for each selected unassigned request
1
Select one or more rows in the Unassigned requests report.
2
Right-click to display the shortcut-menu.
3
Select Auto-Generate Workloads.
The Auto-Generate Workloads dialog box appears. For more information, see the AutoGenerate Workloads dialog box options in To create a separate new workload for each
selected row and see step 5.
4
Select the options.
5
Click OK.
Teradata WA creates a new workload for each unassigned row containing the Criteria #1
attributes.
To create a workload from wild card filters
A workload can be created from wild card filters for quick specification of classifications.
1
Right-click in the Unassigned requests report. The shortcut-menu displays.
2
Select Add Workload using wild card. The Select Wildcard dialog box displays.
3
The options for the Select WildCard dialog box are described in the table below.
61
Option
Description
WildCard Name
Enter the name of the wild card, with one of the
following supported wild card symbols:
• Asterisk (*) - use the asterisk symbol to represent a
missing character. For example, if you enter $M* as
your search term, your results might return $M$abc,
$M$def, and so forth.
• Question mark ( ?) - use the question mark symbol to
represent one unknown character. Use it when you
have a list of similar names, or are unsure of a few
characters.
62
Selected WildCard List
Displays the list of wild cards created.
Add to New Workload
Click to add the selected row to a new workload.
Auto-Generate Workload
Click to automatically generate a new workload from the
selected row.
4
Type the wild card name in the WildCard Name text box and click >>. The wild card name
displays in the Selected Wild Card List list, and results of the wild card search display in the
report below.
5
Select the row in the report and click Add to New Workload. See the table in step 4 of
“Grouping Unassigned Requests Into a Workload” on page 58 to complete the options for
this dialog box.
6
To auto-generate the selected row, click Auto-Generate Workload. See step 3 in “To create a
separate new workload for each selected row” on page 71 to complete the options for this
dialog box.
The newly created workload displays in the Workload Report.
Step 2: Refining and Analyzing Recommended
Workloads
Generating the initial workload recommendations after grouping accounts, applications,
users, and profiles identified in those recommendations are preliminary steps toward
optimizing the highest resource consumers on a system.
Although analysis can stop at this level, further optimization may be achieved by refining the
recommended workloads. This represents the second level of analysis, in which additional
who, what, and where parameters are chosen for further classification of the workloads. This
additional level of classification enables identification of other similarities among workloads
so that they will run even more efficiently.
This section provides information how to refine and analyze workloads at a basic level.
Teradata WA also offers the ability to apply a recursive analysis of workloads with different
correlation and distribution parameters. See “Using Deep Drill-Down and Refinement for
Workload Analysis” on page 96 for more information.
Supported Analysis Parameters
Teradata WA supports the Who, What, Where, and Exception parameters described in Table 8.
Table 8: Supported analysis parameters
Parameter Criteria
Parameter
Who
•
•
•
•
•
•
•
•
•
Account Name
Account String
Application
Client address
Client ID
Profile
Username
Query Band
UtilityType
What
•
•
•
•
Estimated processing time
Result Rows
AMP Count
Statement type
63
Table 8: Supported analysis parameters (continued)
Parameter Criteria
Parameter
Exception Parameters (subset of “What” Parameter)
•
•
•
•
Where
IO count
Spool Usages
Normalized CPU Time
UnNormalized CPU Time
• Data objects
• Database
• Tables
• Views
• Macros
• Stored procedures
• Function
• Method
Analyzing Workloads Based On “Who” Parameters
To analyze a workload based on “who” parameters
1
In the Candidate Workload Report window, right-click over the workload to be analyzed in
the Workloads Report.
The Workloads Report shortcut menu displays the menu options described in the
following table.
Table 9: Workloads Report shortcut menu
64
Option
Description
Workload Details
Displays the workload details in the Workload Attribute
tabbed screen.
Analyze Workload
Analyzes the workload based on “who” or “what”
parameters (second level of analysis). This will invoke the
Analyze Workload window.
Merge Workload
Merges workloads.
Split Workload
Splits workloads.
Calculate SLGs
Calculates the service level goals for the selected
workload.
Rename Workload
Renames the workload.
Delete Workload
Deletes the workload from the Workloads Report.
Table 9: Workloads Report shortcut menu (continued)
2
Option
Description
Delete Assigned Request
Removes the assigned requests from the Workload
Report. The deleted items are automatically re-displayed
in the Unassigned requests report. This option is
available only when a detail row (not a workload
aggregation row) is selected.
Calculate All WDs SLGs
Calculates SLG Goals for all defined workloads
Workload to AG Mapping
Performs WD to AG mapping (same as existing WD to
AG option)
Save Report As
Saves the workloads report to a file (in either .xml, txt or
html formats).
Print Report
Prints the workloads report.
Hide Details
Hides or shows the cluster details. Only workload rows
are displayed when Hide is selected.
Select Analyze Workload.
Note: Alternatively, expand the node next to the workload to be analyzed under the
Candidate Workloads tree, then select Analyze.
The Analyze Workload window appears.
65
3
Complete the following options as appropriate to analyze the workload as described in the
following table.
Note: To display the total number of elements for correlation parameters, and the total
available maximum and minimum ranges for distribution parameters, see “Configuring
Application Options” on page 29.
Option
Description
OpEnv
Displays the system setting for the operating
environment (period event). The default setting is
‘Always,’ with precedence of one. You can select one or
more OpEnvs to analyze with the workload.
Syscon
Displays the system setting for the system condition. The
default setting is ‘Normal,’ with severity of one as part of
the new rule set. The default setting cannot be deleted.
You can select one or more Syscons to analyze the
workload.
Workload Correlation Parameter
Lists the available “Who” and “Where” parameters to
substitute for the ones previously used. For example, if
account-based parameters were used initially, this list
displays application-based and object-based parameters
in case they provide more efficient workloads. Click the
appropriate parameter for the workload you want to
refine.
Queryband Filter Name
Lists the available query band names. The query band
names are automatically loaded when the Analyze
Workload tab displays. The number next to each query
band name represents the number of distinct value
counts.
The Analyze Workload tab displays which query band
the analysis is based on.
Figure 8: Example of report with query band name displayed
Load
66
Click to refresh the list of query bands.
Option
Description
Workload Distribution Parameter
Lists the available “What” and “Exception Criteria”
parameters. Select the appropriate distribution
parameter to view the analysis graph for the selected
correlation parameter (based on queries distribution on
the selected “What” and “Exception Criteria”
parameter). The default distribution parameter is CPU
Time. Normalized CPU Time is the default distribution
parameter.
Distribution Buckets
Enter the number of histogram buckets to distribute the
resulting distribution parameter values into. For
example, if the correlation parameter is Client ID and the
distribution parameter is CPU Time, and the bucket
number is ten, then the total CPU Time value is divided
into ten equal histogram buckets and the report displays
how the top Client IDs are distributed among the bucket
values.
The default distribution is ten histogram buckets.
Figure 9: Example of Distribution Parameters with ten
buckets
Arrival Rate/Throughput
Lists the Start and End dates to analyze Arrival Rate/
Throughput for the selected correlation parameter. The
lists are enabled if Arrival Rate/Throughput are selected
as the distribution parameter. This option is enabled
when Arrival Rate or Throughput are selected as
Distribution Parameters
67
Option
Description
Group By
Select the Hour option to group selected Arrival Rate/
Throughput days by the hour. For example, if the Start
Date is 11/20/06 and End Date is 11/23/06, the hours
would be grouped as follows: zero hour from 11/20 to 11/
23, first hour from 11/20 to 11/23, second hour, and so
forth.
Select the Date option to group the selected days by the
date of each day.
4
Perform Analysis
Displays the Graph tab with the selected Data Filter
settings. A workload analysis report and distribution
graph display.
DBQL Date Range
Displays the starting and ending date range of data
collected.
Select Workload
Lists the name of the candidate workloads. Click the
workload to be refined.
View Classification
Click to view the classification of the current workload
displayed in the Current Workload Classification list after
each level of analysis is performed.
View Exception
Click to view the exception of the current workload
displayed in the Current Workload Classification list after
each level of analysis is performed.
Current Workload Classification
Lists the workloads currently being classified. The
number next to each workload classification represents
the distinct value counts within all possible correlation
parameters. For example, Account Name (3) means that
there are a total of three accounts classified.
Undo Classification
Click to restore the workload to the previous
classification. The workload must be selected from the
Current Workload Classification list to be undone.
Workload classifications may be undone more than once.
Classifications added with the Add to option can be
undone. First-level analyses cannot be undone.
Click Perform Analysis to analyze the selected workload with the chosen options.
The Analyze Workloads results are displayed with a graph.
68
The following options for the Graph tab are described in the following table.
Option
Description
Correlation Parameter option
Displays Correlation Report information in the graph.
Distribution Parameter option
Displays the Distribution Report of the correlation
parameter plus distribution parameter that is displayed.
For example, if CPU Time is the selected distribution
parameter, then the distribution of CPU Time of the
selected correlation parameter is displayed.
Workload Name
Displays the name of the current workload being viewed.
Correlation Report by
Displays the selected correlation parameter that the
report is based on.
Distribution Report by
Displays the selected distribution parameter that the
report is based on.
Top N Value text box
Enter the number of resource-intensive workloads to
analyze. The default number is 10.
Refresh button
Redisplays the graph with the newly selected parameters.
Home button
Redisplays the Analyze Workload tab with the Data
Filters tab.
Zoom In - Zoom Out
Changes the granularity of the graph view.
The Graph tab allows you to select a distribution or correlation parameter to analyze for a
particular workload. For example, if the correlation parameter is ClientID, and the
69
distribution parameter is Response Time, the analysis displays a report for the distribution
of Response Time based on found ClientIDs for the selected workload.
Creating New Workloads From Groups Of Existing Workloads
To create a new workload by grouping existing workloads
1
From the Analyze Workload tab, select the Correlation Parameter option in the View By box.
2
Select one or more rows in the Analyze Workloads report with the attributes to be flagged,
for example, “high CPU usage.”
3
The Analyze Workloads report shortcut-menu displays the options described in the
following table.
Option
Description
Split to New Workload
After selecting a single row or block of rows in the
Analyze Workload report, choose this option to create a
new workload with all the selected classifications. The
selected row is removed from the report and the graph is
updated with the remaining unassigned clusters.
Add clusters for Deeper analysis
Click to add selected clusters to the current workload for
deeper analysis.The selected cluster is removed from the
report and the graph is updated.
Note: This option is disabled for original workloads. The
Split Workload option allows for a new workload to be
created. See Table 9 on page 64 for more information.
The Add To option is then enabled for further workload
classification.
4
Auto-generate Workloads
Select this option to automatically generate a new
workload for each selected row.
Update Graph and Distribution
Report
Select this option to update the report and redraw the
graph to include changes.
Save Report As
Select this option to save report in .txt, .html, or .xls
format.
Select Split to New Workload.
70
5
Fill in the Add Workload dialog box to describe the new workload.
6
Click Preview Classification to view the classification of the workload to be created. A
read-only Classification window displays with the classification criterion of the workload.
7
Click OK.
Teradata WA creates a new workload containing both the Criteria #1 and Criteria #2
attributes.
Creating a Separate New Workload for Each Selected Row
Teradata WA creates a new workload for each row containing the Criteria #1 and Criteria #2
attributes.
To create a separate new workload for each selected row
1
Select Correlation Parameter in the View By box.
2
Select one or more rows in the Analyze Workloads report with the attributes to be flagged,
for example, “high CPU usage.”
3
4
Select Auto-Generate Workloads.
The Auto-Generate Workloads dialog box appears.
71
5
6
Select an option as described in the table below.
Option
Description
requirement.
resources.
time requirement.
Click OK.
Analyzing Workloads Based On “What” Parameters
Teradata uses equal-width and equal-height histograms in analyzing what parameters.
Equal-Width Versus Equal-Height Histograms
A histogram is a vertical bar chart in which the frequency corresponding to a class is
represented by the area of a bar (or rectangle) whose base is the class width. The histogram
differs from a bar chart in that it is the area of the bar that denotes the value, not the height.
However, if the widths of the bars are uniform (that is, equal-width) then only the height need
be considered.
Teradata WA uses both equal-width and equal-height histograms in analyzing the what
parameter.
Equal-Width Histograms
An equal-width histogram such as that shown in Figure 10, divides data into a fixed number
of equal-width ranges. The corresponding height of each range represents the number of
values falling into that range.
72
Figure 10: Equal-widths histogram
For example, suppose that the values in a single column of a 1000-row table range between 1
and 100, and you want to generate a 10-bucket equal-width histogram. (Ranges in histograms
are often referred to as “buckets.”) The buckets would contain the values 1-10, 11-20, 21-30,
and so on, where each bucket counts the number of rows falling into its range. For a list of
supported analysis parameters, see Table 8 on page 63.
Equal-Height Histograms
Equal-width histograms work well when the variation of the data distribution is small. They
do not work so well, however, when such variation is large. For example, in Figure 10, 95% of
the data falls into the first bucket, and the remaining 1% is scattered into 19 buckets, making it
difficult to effectively analyze the data.
In this situation, an equal-height histogram is the solution, such as that shown in Figure 11.
Such histograms work well when the variation in data distribution is large. Unlike equalwidth histograms, they place the same number of values into each range, so the endpoints of
each range are determined by the number of values it contains.
73
Figure 11: Equal-height histogram
The graph isn't as informative as the bin-widths identified on its x-axis. They reveal that not
only are the vast majority of data points in the 0-8.41 range, but provide additional insight
that the vast majority of queries (80%) consume less than 0.01 CPU secs.
This information is provided in a pop-up dialog box for each equal-height histogram. For
instructions on viewing histograms and their data, see step 6 on page 76
Displaying a “What” Parameter Histogram
To display a “what” parameter histogram
1
From the Candidate Workloads tree, expand the workload to be analyzed.
2
Select Analyze Workload.
The Analyze Workload window appears.
74
3
Select the appropriate “what” options in the Workload Distribution Parameters list.
Note: See the table following step 3 in “To analyze a workload based on “who”
parameters” on page 64 for more information about Analyze Workload window options.
4
Click Perform Analysis to analyze the selected workload with chosen options.
By default, the Analyze Workload window creates an equal-width balanced histogram,
dividing the total selected distribution parameter into the number of buckets specified in
the Top N Value field. Each bucket contains equal amounts of the selected distribution
parameter and the total query count lies in that bucket.
5
To view the corresponding equal-height histogram, click the Switch to Equal-Height
Histogram button on the Analyze Workload tab.
You can also right-click the histogram itself and select Equal-Height Histogram from the
menu that appears.
75
6
To view the Equal-Height Distribution report associated with the histogram, select View
Equal-Height Table.
The table appears similar to the following.
Creating a New Workload From a Particular Bucket In the
Histogram
For this procedure, Estimated Processing Time is used as an example.
To create a new workload from a particular bucket in the histogram
1
From the Estimated Processing Time histogram, highlight the bucket to be analyzed, then
right-click.
The shortcut menu appears. See “To add an existing classification to a new workload” on
page 81 and see step 2 for more information.
76
2
Select the Split to New Workload option.
The Estimated Processing Time dialog box appears.
3
Enter the minimum and maximum processing time bucket parameters.
4
Click OK.
5
Enter the workload attribute details. See the table after step 4 of “To group unassigned
requests into a workload” on page 58 for more information.
6
Click OK.
A new workload is created with Minimum and Maximum Estimated Processing Time
along with the first level of classifications. The selected row/bucket is removed from the
Analyze Workload report.
77
Zooming In On a Histogram Bucket For More Detail
To zoom in on a bucket for more detail
For this procedure, Estimated Processing Time is used as an example. Zooming in on a bucket
creates another Top N Values within the bucket, presenting a finer view of the distribution.
1
From the Estimated Processing Time histogram, right-click the bucket to zoom in on.
2
Select Zoom In from the short-cut menu.
The Zoom In dialog box appears.
3
Enter the minimum, maximum processing time, and the number of bucket parameters,
and Click OK.
After processing, the bucket is displayed as a new histogram.
4
To reset the zoom to the previous level, right-click and select the Zoom Out option.
Rounding Up Equal-Width Buckets for More Intuitive Number
Recognition
The widths of equal-width buckets are calculated by dividing the highest value by the number
of buckets. While technically accurate, this method may not be intuitive to the user. Rounding
up the calculation of the widths used in equal-width buckets may improve the usability of the
buckets while making a small sacrifice in their accuracy.
The rounding up of bucket widths is based on calculating the maximum value and then
rounding it up so that the last bucket covers the maximum value. For example, if you have a
large range of numbers with the highest value = 3876.77, and want to split the values into 10
buckets, then the bucket size is calculated as 3876.77 / 10 = 387.677. If this is rounded up to
400, then the revised buckets would have the following values: 0- 400, 401-800, 801-1200, ...,
3201-3600, and 3601-4000. These new buckets would then be reflected in the distribution
report shown in Figure 12.
78
Figure 12: Distribution report after rounding up the widths of buckets for data with a large range of values
For data with a small range of values where the highest value = 3.15, split into 10 buckets,
bucket width is calculated as 3.15 / 10 = 0.31, rounded to 0.40. The revised buckets are then
split into these values: 0-0.40, 0.41-0.60, 0.61-1.0, ..., 3.21-3.6, and 3.61 - 4.00 as reflected in
the distribution report in Figure 13.
79
Figure 13: Distribution report after rounding up the widths of buckets for data with a small range of values
Displaying Columns in the “what” classification of the Analyze
Workload Report
To display the columns in the “what” classification Analyze Workload report
✔ Select Distribution Parameter.
Table 10 describes the displayed columns in the “what” classification Analyze Workload
report.
Table 10: Columns in the Analyze Workload report - “what” classification
Column Name
Description
Estimated Processing Time
The minimum and maximum estimated processing time and
the number of queries that completed during this collection
interval for this bucket
Min, Max, Query Count
80
AMPs for this bucket
and writes) issued across all AMPs for this bucket
Table 10: Columns in the Analyze Workload report - “what” classification (continued)
Column Name
Description
Average Est Processing Time
The average estimated processing time for each query
Normalized CPU per Query
(Seconds)
percentile and maximum expected CPU time for queries in
this bucket.
Max
UnNormalized CPU per Query
(Seconds)
Max
Response Time (Seconds)
Result Row Count
Disk I/O Per Query
CPU To Disk Ratio
Active AMPS
Spool Usage (Bytes)
CPU Skew (Percent)
I/O Skew (Percent)
percentile and maximum expected UnNormalized CPU time
for queries in this bucket.
response time for queries in this bucket
result rows returned for this bucket
disk I/O’s per query for this bucket
CPU/Disk ratio for this bucket
number of active AMPs for this bucket
spool usage across all VProcs for this bucket
AMP CPU skew for this bucket
AMP I/O skew for this bucket
Adding Existing Classifications to New Workloads
To add an existing classification to a new workload
1
From the Analyze Workload window displaying the previously analyzed workload, click the
Distribution Parameter option in the View By box. The Distribution Report displays with
the selected distribution parameter by correlation parameter.
2
Highlight the bucket to be analyzed, then right-click.
The shortcut menu appears. See the following table for descriptions.
81
Option
Description
Split to New Workload with (selected
Distribution Parameter) as Classification
Select this option to add a new workload with
the selected distribution parameter as
classification.
This shortcut menu option displays when
Result Rows, AMP Count, or Estimated
Processing Time is selected from the
Distribution Parameter list on the Analyze
Workload tab.
Add (selected Distribution Parameter) as
classification to workload
Select this option to add the selected
distribution parameter as an additional
criterion to the workload.
This shortcut menu option displays when
Result Rows, AMP Count or Estimated
Processing Time is selected from the
Distribution Parameter list on the Analyze
Workload tab.
82
Zoom In
Select this option to change the granularity of
the graph view.
Zoom Out
the graph view.
Save Report As
Saves the workloads report to a file (in either
.xml, txt, or html formats).
3
Select Split to New Workload with (selected Distribution Parameter) as Classification. The
Add Workload dialog box appears. See table to complete the options.
4
Click OK. A new workload is created from the selected workload. The new workload
contains the parent workload’s classifications, along with the new criteria.
Analyzing Workloads Based on Exceptions
Teradata WA supports the following exception parameters:
•
Unnormalized CPU Time
•
Normalized CPU Time
•
IO Count
•
CPU Time
•
Spool Size
•
Response Time
Analyzing Workloads Based On Exception Parameters
To analyze a workload based on exception parameters
1
In the Candidate Workload Report window, right-click over the workload to be analyzed.
The Workloads Report shortcut menu appears.
2
Select Analyze Workload. The Analyze Workload window appears.
Note: Alternatively, expand the node next to the workload to be analyzed under the
Candidate Workloads tree, and then select Analyze.
3
Click on the Distribution Parameter drop-down, and select the exceptions and actions.
4
Enter the number of Distribution Buckets. The default number of buckets is 10.
5
Click Perform Analysis to analyze the selected workload with the chosen exception
parameters.
A same-width histogram displays for the selected workload and correlation parameter.
Creating a Workload with Exception from Analyzed Values
To create a workload with exception from the analyzed values
1
From the Analyze Workload window with the previously analyzed workload with
exceptions, click the Distribution Parameter option in the View By box.
2
Right-click over the bucket row to analyzed. The Workloads Report shortcut menu for the
Distribution Parameter view appears. See the following table for descriptions.
83
Option
Description
Split to New Workload with (selected
Distribution Parameter) as Exception
Select this option to add a new workload with
the selected distribution parameter as the
Exception.
This shortcut menu option displays when CPU
Time, Response Time, IO Count, or Spool
Usage (bytes) is selected from the Distribution
Parameter list on the Analyze Workloads tab.
Add (selected Distribution Parameter) as
Exception to workload
Select this option to add the selected
distribution parameter as a user-defined
exception criterion for the highlighted
workload.
This shortcut menu option displays when CPU
Time, Response Time, IO Count, or Spool
Usage (bytes) is selected from the Distribution
Parameter list on the Analyze Workloads tab.
3
84
Zoom In
the graph view.
Zoom Out
the graph view.
Save Report As
Saves the workloads report to a file (in either
.xml, txt, or html formats).
Select Split to New Workload with (selected Distribution Parameter) as Exception. The Add
New workload With Exception dialog box displays.
4
Select the options as described in the following table:
Option
Definition
Workload Name
Name of the workload.
Preview Classification
Click to view the classification of the workload to be
created. A read-only Classification window displays with
the classification criterion of the workload.
Workload Description
Exception Type
Displays the Exception parameter to be used for the
exception.
Exception Name
Name of the exception parameter.
WD Enforcement Priority
Tactical - short queries with a fixed response-time
requirement.
Priority - important queries that should get extra
resources.
Normal - normal queries; this is the default.
Background - low-priority queries with no response time
requirement.
85
Option
Definition
Exception Actions
No Exception Monitoring - Only log the exception.
Continue and Log - Logs the exception and choose
another action.
Abort and Log - Log the exception and abort the request.
Abort On Select and Log - Log the exception and abort
the request only if it was a select that did not modify
tables.
Change Workload - Log the exception and move the
request to the specified workload.
Raise Alert - Log the exception and raise the specified
alert through Teradata Viewpoint Alert Setup. For more
information, see Teradata Viewpoint User Guide
(B035-2206).
Note: Teradata Viewpoint Data Collection Service
(DCS) monitors database tables and sends alerts to
Teradata Viewpoint Alert Viewer for processing.
Teradata Viewpoint Alert Viewer allows users to view
and manage alerts.
Run Program - Log the exception and run the specified
program using Viewpoint Workload Monitor.
For more information, see the Teradata Viewpoint User
Guide (B035-2206).
5
Click OK. The newly created workload with exception appears in the Candidate Workloads
tree.
Adding Exception Criteria to an Existing Workload
To add exceptions to an existing workload
86
1
From the Analyze Workload window with the previously analyzed workload with
exceptions, click the Distribution Parameter option in the View By box.
2
Right-click over the bucket row to analyzed. The Workloads Report shortcut menu for the
Distribution Parameter view appears.
3
Select Add (selected Distribution Parameter) as Exception to workload. The Add Exception
to Existing WD appears.
4
Select the options as described in the following table:
Option
Description
Exception Name
Name of the exception parameter
Exception Type
Displays the Exception parameter to be used for the
exception.
Exception Max Value
The maximum value of the selected exception
parameter.
87
Option
Description
Exception Actions
No Exception Monitoring - Only log the exception.
Continue and Log - Logs the exception and choose
another action.
Abort and Log - Log the exception and abort the request.
Abort On Select and Log - Log the exception and abort
the request only if it was a select that did not modify
tables.
Change Workload - Log the exception and move the
request to the specified workload.
Raise Alert - Log the exception and raise the specified
alert through Teradata Viewpoint Alert Setup.
Note: Teradata Viewpoint Data Collection Service
(DCS) monitors database tables and sends alerts to
Teradata Viewpoint Alert Viewer for processing.
Teradata Viewpoint Alert Viewer allows users to view
and manage alerts.
Run Program - Log the exception and run the specified
program using Viewpoint Workload Monitor.
For more information, see the Teradata Viewpoint User
Guide (B035-2206).
5
Click OK. A message appears confirming the addition of the exception to the selected
bucket row.
6
Click OK. The message dialog box closes, and the selected bucket row for the exception is
removed from the Distribution Report.
Step 3: Defining Service Level Goals to Get the
Most Out of Reports
Service Level Goals (SLG) are benchmarks that can be set so the effectiveness of workload
management can be analyzed.
How Teradata WA Sets SLGs
Teradata WA recommends service level goals for workloads to achieve the greatest
responsiveness. Teradata WA sets goals using current performance as a baseline. For example,
Teradata WA might detect that, under current performance, for 80 percent of queries, the
maximum response time is 300 seconds. Therefore, Teradata WA would set the service-level
goal for response time as 80 percent, meaning that 80 percent of queries process in less than
300 seconds. The user can choose to accept the recommended goals or modify various settings
as reporting needs dictate.
Using service level goals is recommended, although not required.
88
Service Level Goals and Viewpoint Workload Monitor
Assigning Service Level Goals to tactical and priority workloads will provide a reference point
in the Viewpoint Workload Monitor, creating a visualization of how well the workloads are
performing.
Note: SLGs for workloads that have long, varied response times have little value and will
expand the Viewpoint Workload Monitor response time graph scale making it difficult to read
the response times of tactical workloads.
Accepting Or Modifying Service-Level Goal Recommendations
To accept or modify service-level goal recommendations
1
Under Candidate Workloads, expand the selected workload, then click on the SLG Graph
icon.
The SLG Recommendations window appears.
Note: Alternatively, the SLG Recommendations window can be displayed by selecting Rule
Set > Workloads> Calculate SLGs from the Teradata WA menu.
2
In the SLG Recommendations window, view the default parameters and resulting service
level recommendations, along with the displayed chart. Change the options as described in
the following table.
89
Table 11: SLG Recommendations
Option
Description
SLG Parameters
Displays the service parameters that you can view or modify to
generate Teradata WA SLG recommendations. Click a service
parameter in the list or accept the default (Response Time) as
appropriate.
• this parameter appears as the horizontal axis of the chart
• the value of this parameter can be edited in the SLG
Recommendations table displayed beneath the chart; no other
options are available for editing.
immediately.
OpEnv
Displays the available operating environment. Click operating
environment (OpEnv) in the list box or accept Default as
appropriate.
immediately.
Set Manually
Allows modification of the recommended service levels. This
checkbox is unchecked by default.
Recommended SLG
Changes the selected service parameter’s recommended value
(shown highlighted in white). No other values are available for
editing (shown shaded).
are displayed. The response time goal shown is the value that
would satisfy a 80% goal.
3
Service percent
recommendations. Adjust this as appropriate.
Factor by
Modifies the SLG parameter, with a factor of 1 being the same as
today, 0.1 being 10 times faster than today, 10.0 being 10 times
slower than today.
When satisfied with the new values, click Apply.
Step 4: Mapping Workloads to Allocation
Groups
There are two strategies for automating the determination of priority settings in Teradata WA:
Either by Category of Work or by Subject Area Resource Division. Priorities can also be set
manually, by defining specific allocation groups and resource partitions.
90
Category of Work
Category of Work allocates weight based on importance of the workload; it is best suited for
tactical or priority workloads. If Category of Work is selected, Teradata WA assigns AGs, RPs
and default weights for each enforcement priority type as shown in Table 12. Therefore, it is
only required that enforcement priorities are associated to workloads; the RPs and AGs are
already set up. (Selecting the Category of Work approach removes any previously defined RPs
or AGs.)
Table 12: Default AG and RP Weights for Priority based on Category of Work
Enforcement
Priority
AG
AG Weight
RP
RP Weight
Global Relative
Weight (GRWs)
Tactical
Tactical-AG
20
Tactical-RP
60
75%
Priority
Priority-AG
40
Standard-RP
20
16%
Normal
Normal-AG
20
Standard-RP
20
5%
Background
Backgnd-AG
10
Standard-RP
20
2%
When using the Category of Work approach, there are fewer active allocation groups, with
those groups having similar relative weights. However, there will be a clear distinction
between the Tactical and Priority enforcement priority settings.
Workloads defined with the Tactical or Priority enforcement priority must use the Category of
Work approach. They cannot use the Subject Area Resource Division option.
Subject Area Resource Division
The Subject Area Resource Division method allocates weight based on a designated “share” of
the available resources. This approach works best for workloads that run mostly at Normal or
Background priority.
Teradata WA predefines the RPs and weights when using the Subject Area Resource Division
method; AGs and weights can be user-defined.
When the Subject Area Resource Division approach is in use, there are more active AGs with
less differentiation between the priorities of active AGs.
Note: The Subject Area Resource Division option cannot be used if the workloads are tactical
or priority. In these cases, the Category of Work option must be used instead.
Workload-to-Allocation Group Mapping
As a last step before saving the workload, use Workload-to-Allocation Group mapping to
associate workloads with allocation groups and enforcement priorities. This is useful if
analysis reveals that certain workloads require different enforcement priorities and allocation
groups than those defined for the workload state.
By default, workloads are mapped to AGs and RPs as shown in Table 13.
91
Table 13: Default Mapping of Enforcement Priorities
AG
RP
Tactical
Tactical-AG
Tactical-RP
Priority
Priority-AG
Standard-RP
Normal
Normal-AG
Standard-RP
Background
Background-AG
Standard-RP
Note: Workloads can be grouped in the same AG if they have the same enforcement priority.
Maintaining several separate AGs results in more control, but at the cost of there being less
differentiation between the AGs.
Defining Enforcement Priorities
To define enforcement priorities
1
Select Rule Set > Workload to AG Mapping.
The Set Enforcement Priority dialog box appears.
2
92
In the Set Enforcement Priority dialog box, click the workload to be modified and drag it to
the enforcement priority row. To hide workloads that have already been assigned
enforcement priorities, click the Show Only Unassigned Workloads check box.
The following table describes the available mapping options:
Table 14: Mapping options
Option
Description
State
Displays the state of the system. State is a composite of system
condition and operating environment. The default state is Base,
which represents the mapping of Normal and Always.
Category of Work
With this option selected, Teradata WA recommends standard
resource partition and allocation group weights. Click Reload if
this option is reset.
Subject Area Resource
Division
Select this option if RP weights are already defined and Teradata
WA will recommend only allocation group weights. Click Reload
if this option is reset.
Note: This option is not available if the workloads are Tactical or
Priority.
3
RP Name
The name of the resource partition automatically applied to the
workload.
RP Weight
The RP weight allocated to the workload. This cannot be
changed without changing the enforcement priority.
AG Name
The name of AG applied to the workload.
AG Weight
The AG weight allocated to the workload. This cannot be
Relative Weight
The relative weight associated with the workload. This can be
Displays the currently assigned enforcement priority for the
selected workload. To change the assignment, click Change
Enforcement Priority and modify the Set Enforcement Priority
dialog box.
Assigned Workloads
Displays the names of the workload associated with the
enforcement priority. Note that more than one workload can be
allocated to a particular enforcement priority and allocation
group.
After making the appropriate changes, click OK.
This causes the Workload-Allocation Group Mapping dialog box to appear, where the
method of priority-setting can be selected and the resource partitions and allocation
groups can be modified.
93
4
In the Workload-Allocation Group Mapping dialog box, view the displayed values.
To display the default RP information in the dialog box, click the Show Default RP check
box.
5
Click OK to accept values or Cancel to discard them and start over.
Note: The enforcement priority for a workload can be modified from the Attributes dialog
box under Candidate Workloads.
The workloads defined during each phase of New Workload Recommendation are not created
until the New Workload Recommendation tasks are completed and new workloads have been
chosen for use.
94
Creating a New Workload For Use from Rule Set
To create a new workload for use
1
Select Rule Set > Save to Database.
The Save Rule Set dialog box is displayed.
2
Enter a name for the rule set or accept the default name.
3
Click OK to save the new workload for use.
Note: The TDWM database is locked as a rule set is saved.
To group accounts, applications, users, or profiles into a workload
1
Select Rule Set > Workloads > New Workload. See the following table for more information
about the Rule Set menu.
Menu option
Sub menu option
Save to Database
Description
Saves the rule set to the TDWM database.
Note: The TDWM database is locked as a rule set is saved.
Workloads
New Workload
Adds a new workload to the Candidate Workload Report
window.
Merge Workloads
Merges selected workloads into a single workload.
Split workload
Splits the selected workload into one or more workloads.
Calculate SLGs
Calculates the service level goals for the selected
workload.
Delete Workload
Deletes a workload from the Candidate Workload Report
window.
Workload to AG
Mapping
Performs the workload definition to allocation group
mapping
Calculate All WDs
SLGs
Calculates service level goals for all defined workloads.
95
Note: The Rule Set menu is available when the Candidate Workload Report window is
open.
2
3
From the Add Workload dialog box, complete the options as appropriate for the new
workload. See the following table.
Option
Description
Name
The name of the workload.
Description
requirement.
resources.
time requirement.
Click OK.
The newly created workload now displays in the Workloads Report section of the Candidate
Workload Report window.
Using Deep Drill-Down and Refinement for Workload Analysis
This section describes the use of deep drill-down analysis and refinement of workloads. Deep
drill-down and refinement of workloads can be executed during the second level of analysis.
For information about basic second level workload analysis, see “Step 2: Refining and
Analyzing Recommended Workloads” on page 63.
This section includes the following:
96
•
Overview of Deep Drill-Down and Refinement
•
How Does Deep Drill-Down Analysis Work?
•
Example 1: Deep Drill-Down Analysis
•
Example 2: Deep Drill-Down Analysis with Queryband Parameters
Overview of Deep Drill-Down and Refinement
After one or more workloads are defined in the initial phase using first level of parameters
(Account, Applications, User and Profiles), the Candidate Workloads Tree on the left pane is
refreshed with the initial set of workloads.
Teradata WA provides the capability to continuously drill-down on a workload with various
“Who”, “What”, “Where” and “Exceptions” parameters (see Table 8 on page 63 for a list of
parameters). It can visualize distinct clusters of requests within the workload, each with
distinct service time patterns and other characteristics.
For example, an initial workload defined on just the Account parameter may include distinct
users who execute tactical requests requiring higher priority, while the remaining users do not.
Teradata WA helps the DBA identify these clusters by providing reports, correlation graphs
and distribution graphs (with parameters such as CPU, Response Time, Estimated Processing
Time, for example) on different dimensions.
Analysis of an individual workload is initiated by selecting the Analyze Workload option on the
Workload Report shortcut menu (see the table following step 1 on page 64) or by clicking
Analyze under the workload to be analyzed in the Candidate Workloads Tree. To further refine
the initial set of workloads into one or more additional workloads, Teradata WA uses DBQL
data for workload analysis.
Theoretically, a workload can be subclassified further into multiple workloads through
additional classification criterion. Subclassification on any and all possible classification
criterion may be confusing and result in many unnecessary workloads. Considering the
operational performance points, there is a maximum limit on the number of workloads for a
database.
Teradata WA guides the DBA towards the appropriate classification criterion. At any given
point in the analysis, the DBA is allowed to choose correlation and distribution parameters in
the drop-down list, and analyze the associated usage patterns. The DBA could drill deeper in
analysis within a chosen cluster, or re-analyze by choosing different correlation and
distribution parameters. Through trial-and-error and visualization, the DBA decides which
parameters identify the ideal request group to isolate the most effectively. This trial-and-error
process is streamlined by providing the DBA with distinct count and distribution range
insight without having to click Analyze Workload. This time saving process eliminates
unproductive visualizations on a single user, or a tight distribution, for example.
The overall flow of workload analysis with deeper drill-down and refinement is represented in
Figure 14.
97
Figure 14: Overview of deep drill-down analysis
Select initial workload and correlation distribution parameters for analysis
Click Perform Analysis to view Cluster Report and Distribution Graph
Add correlation clusters and distribution buckets as classification and
exception on existing WD/Split WD
WD
Classifications
OK?
NO
Undo/Next
Level of
Analysis
YES
Analysis Completed
Revised WD
Classifications
and Exception
Criteria
Select another workload for
Analysis/Drill Down
CREATE WORKLOADS
DONE
2514A011
How Does Deep Drill-Down Analysis Work?
Deep drill-down analysis is a recursive process for deeper analysis on correlation and
distribution parameters. If current analysis parameters do not satisfy the DBA, more
appropriate parameters can be selected by reviewing the distinct values and ranges for other
parameters.
For example, with respect to the distinct value counts, one particular workload could display
the following characteristics:
98
•
UserName (24)
•
Applications (1)
•
Account Name (1)
•
Client Addresses (2)
•
Queryband (3)
•
Function (3)
•
Urgency (1)
•
AggLevel (8)
•
Estimated Processing Time (zero to 1000 seconds)
•
AMP Count (zero to 1)
Note: See “Configuring Application Options” on page 29 for information on viewing distinct
value counts in workloads.
In this example, the DBA now knows that there is only one distinct Application and one
distinct Account, and that they both run at the same urgency. Attempting to identify a
correlation against a different Application, Account or urgency values is a wasted effort.
However, the opportunity for correlation does exist with User Name, Function and AggLevel.
The DBA could pursue those correlation options. For the distribution parameter ranges, an
Estimated Processing Time range from zero to 1000 seconds suggests that a large variation of
requests are included in this workload. The opportunity for identifying clusters is higher with
this range, than if the Estimated Processing Time range was just zero to one second.
The DBA may add clusters to the current workload for deeper analysis, or clusters may be split
off into a new workload. The DBA may repeat this process until good set of workloads are
defined, or all unassigned clusters are assigned to workloads.
Teradata WA uses an assigned and unassigned cluster concept. Each cluster (for example,
Accounts, Users, QueryBands) found during analysis are initially unassigned. Selected clusters
are assigned after adding clusters to the current workload for deeper analysis, or after splitting
out into a new workload. The unassigned clusters remain available for subsequent action by
the DBA, if wanted. Teradata WA brings back all unassigned clusters if the same analysis
parameter is clicked again, after displaying an informational message.
If unassigned clusters are not used by the DBA, the associated requests are relegated to a
different workload after the ruleset changes are saved. For example, consider the following set
of six workloads that were generated after the first level of analysis on Accounts, where
Workload A is defined for classification Account=A:
99
Figure 15: Workload A with classification Account =A
after 1st level analysis
(no unassigned requests)
A
35%
2514A018
The DBA decides to analyze workload A, which consumes 35% of the CPU. Based on some
criteria (for example, Client User), it is determined that one element should be isolated, and
treated differently than the other elements. The DBA can either split the existing workload, or
add classification to existing the workload.
If the DBA splits the particular element, the result is a new workload, A2, with classification
Account=A and Client User = xyz. Workload A2 automatically has a higher evaluation order
than the original workload A to assure client users of xyz execute within workload A2, and all
other client users execute within workload A. The CPU distribution divided between the old
workload (A) and new workload (A2) workload is shown in Figure 16:
Figure 16: Workload A and Workload A2 with CPU distribution division
after drill-down split
(no unassigned requests)
A
28%
A2
7%
2514A019
Alternatively, if the DBA chooses to instead add classification to an existing workload, (so that
the workload classification of workload A is now Account=A, and Client User = xyz), the
unselected elements are designated “unassigned,” as depicted in Figure 17. If not further acted
upon, the unassigned elements end up executing within WD-Default, because no other
workload exists that would capture requests with classification Account=A and NOT client
user = xyz.
100
Figure 17: Unassigned elements after classification is added to existing workload
after drill-down "add to"
A
7%
Unassigned
28%
2514A021
To avoid accidental relegation of unassigned clusters to WD-Default, or some other
unexpected WD, drill-down probes should begin the first analysis step using the Split
Workloads option (see “Splitting and Merging Workloads for Analysis” on page 135 for more
information). Additional refinements are done using the Add (selected parameter) as
classification to workload option against that new workload, so that unassigned requests are
relegated back to the original workload. See “Adding Existing Classifications to New
Workloads” on page 81 for more information). See “Example 2: Deep Drill-Down Analysis
with Queryband Parameters” on page 109 for a demonstration on this particular technique.
The DBA selects correlation parameters (“Who” and “Where”) and the distribution
parameters (“What” and “Exception”) at each depth of analysis (see Table 8 on page 63 for the
list of supported parameters). The DBA can also review the workload by viewing the
classification list after each level of analysis and click Undo Classification (if needed). The
Undo operation is used to reverse any previous analysis performed. The operation deletes
assigned clusters from a workload classification and bring them back as unassigned clusters
for new add/split operations.
Note: After PSA migration, when a CPU distribution pie chart is generated for 250 or more
workloads, Teradata WA 14.10 displays the distribution of the top 10 workloads as determined
by the percentage of CPU processing required for each workload. The remaining workloads
are grouped into a segment labeled SUM of CPU % as shown in Figure 18.
101
Figure 18: Distribution of top 10 workloads represented as a percentage of CPU processing when more than 250
workloads are represented after PSA migration.
Example 1: Deep Drill-Down Analysis
Follow this example to learn more about deeper drill-down analysis in Teradata WA.
Example of deep drill-down analysis
1
•
Click
•
Select Analysis > New Workload Recommendations.
•
Press Ctrl+W.
102
2
Complete the Define DBQL Inputs options. For more information, see “Defining DBQL
Inputs” on page 52. In the Category box, select Account String.
3
Click OK. Teradata WA queries the DBQL. The query process may take several minutes.
The Candidate Workload Report window appears with the Unassigned requests report.
4
Select all the unassigned requests in the Unassigned requests report, and right-click to
display the shortcut menu.
5
Select Add To>New Workload.
The Add Workload dialog box appears. For this example, the workload is named WD_ABC.
The new workload displays in the Candidate Workloads Report.
At this point, the CPU distribution of all workloads (1) is 100 percent.
103
WD_ABC
100%
2514A022
6
Right-click over WD-ABC for cluster analysis, and select Analyze Workload.
The workload is analyzed and the Analyze Workload window appears.
104
The Current Workload Classification list displays a summarization of the classification. The
numbers adjacent to the current classification criteria type show the total number of
elements for correlation, and minimum and maximum values for distribution
classification parameters. For example:
•
Account String (2) - There are two Accounts classified
•
Estimated Processing Time (0 - 200 secs) - The workload is classified for Estimated
Processing Time between zero to 200 seconds)
7
Click View Classification to view detailed classification of the workload. Click View
Exception to view the exception definitions.
8
From the Analyze Workload page, select the appropriate correlations from the Workload
Correlation Parameter list and the Workload Distribution Parameter list. Note that there are
10 Applications found for the WD-ABC workload, making this a good candidate to
analyze deeper.
9
Click Perform Analysis. The Correlation Report and graph display.
Note: The workload WD-ABC must be split first from the original workload before
selecting ‘TWA application for deeper analysis.’)
105
Notice in the Correlation Report that the Application ‘TWA’ has a significantly higher CPU,
IO, and Avg Estimated ProcTime values than other Applications in the report. TWA is
selected for deeper analysis.
10 Right-click over TWA, from the shortcut menu, select Add Application clusters for deeper
analysis. The Correlation Report and graph update with the remaining unassigned
clusters, while Application ‘TWA’ is assigned to the current workload for deeper analysis.
11 Click the Data Filters tab at the bottom of the page to view the classification for the current
workload. The Data Filters page displays.
106
The CPU distribution of all workloads now breaks down to 94% for WD-ABC, and 6%
Unassigned.
after drill-down "add to"
Unassigned
6%
WD_ABC
94%
2514A020
Note: If unassigned clusters are not added to current or new split workloads before saving
the ruleset to the database, then all queries arrived for unassigned clusters are executed as
part of the default workload (WD-Default).
If the Application parameter is selected again, all nine unassigned clusters are brought
back for subsequent operations (one cluster is assigned to the current workload).
12 For this example, right-click over the remaining nine clusters in the Correlation Report.
107
13 Select the Split to New Workload option or the Add clusters for deeper analysis option. For
the purpose of this example, Split to New Workload is selected and the new workload is
named WD-Others.
The CPU distribution is now 7% for WD_Others. There are no unassigned requests.
108
after drill-down split the rest
WD_Others
7%
WD_ABC
94%
2514A023
14 Save the rule set to the database for activation. See “Step 5: Creating the Workloads” on
page 94 for detailed instructions.
Example 2: Deep Drill-Down Analysis with Queryband Parameters
This example describes deep drill-down analysis of several query band parameters to help
identify and isolate various request clusters, or provide additional granularity on request
clusters.
In this example, one initial workload consumes the majority of the resources. A more granular
breakdown of that workload is investigated. Long running outliers are noted in the analysis.
The goal is to have these outliers classified into their own workload so that different workload
management techniques are applied.
Example of deep drill-down analysis and query band parameters
1
Select Analysis>New Workload Recommendations. The Define DBQL Inputs dialog box
appears.
2
Inputs” on page 52.
3
In the Category box, select Account String, and click OK. The Unassigned requests report
displays.
4
Right-click over each workload and select Auto-Generate Workloads. The Candidate
Workloads Report displays.
109
The CPU distribution of all workloads is 8% ADW-TACT and 92% ADW-DS. Workload
WD-ADW-DS is selected for further analysis because it is consuming 92% of the total
CPU.
ADWTACT
8%
ADW-DS
92%
2514A025
5
110
Right-click over WD-ADW-DS, and select Analyze Workload. The Analyze Workload page
appears.
There are a total of five distinct query band names. The query bands can be viewed only if
Queryband is selected from the Workload Correlation Parameter list. The five distinct query
band names in this example are:
•
QueryBand (5)
•
AggLevel (7)
•
Function (5)
•
Region (7)
•
TopTierApp (3)
•
Urgency (3)
There are several suitable analysis candidates available in this query band list, as denoted
by the distinct value counts.
6
For this example, select QueryBand as the correlation parameter. Click
query band names in the Queryband Filter drop-down list.
7
Select Function, then click Perform Analysis. The Correlation Report and graph display.
to load the
111
A total of five query band values display for the Queryband=Name function. Notice a
possible distinction with Function=MIN, which included queries with greater time spent
than any of the other queries.
8
112
From the report, right-click over the MIN row, and select Split to New Workload. Name the
new workload WD_ADW_Outliers. This step is done to insure that unassigned clusters fall
back into the original WD-ADW-DS workload classification.
The QueryBand Function=MIN is split to the new workload, ADW-Outliers. The
remaining four functions are unassigned, falling back to ADW-DS if no other action is
taken on them.
after drill-down 1st split
ADWTACT
8%
ADWOutliers
19%
ADW-DS
73%
2514A024
The Correlation/Distribution Reports and graph refresh with the remaining four
unassigned query band values for the next add or split operation.
113
9
114
From the report, right-click over WD_ADW_Outliers and select Analyze Workload to
perform further drill-down analysis. The Analyze Workload page displays.
10 Select TopTierApp from the Queryband Filter list. Click Perform Analysis. The report and
graph display.
The longest running queries not only common to Function=MIN, but also QueryBand
Name TopTierApp=BODSS.
11 From the report, right-click over the BODSS row, and select Add ‘QueryBand’ clusters for
deeper Analysis.
The BODSS value is added to the current analyzed workload, WD_ADW_Outliers.
The CPU distribution now has two unassigned TopTierApps relegated to the original
WD_ADW_DS workload, rather than being part of the WD_ADW_Outliers workload.
115
after drill-down 1st "add to"
ADWTACT
8%
ADWOutliers
17.5%
ADW-DS
74.5%
2514A026
Analyzing further on ADW_Outliers, notice that the distinct count for all the correlation
parameters displays one (only one distinct value).
This means that all requests in this workload are coming from the same combination of
‘Who’ parameters (Account ADW_DS, QueryBand Name Function=MIN, and
Queryband Name TopTier App=BODSS).
Only distribution parameters may be used deeper drill-down analysis. The Estimated
Processing Time may be used as a distribution parameter, since the range for the current
workload is wide (0.00 -0158.00 seconds).
12 From the Analyze Workload page, select None from the Workload Correlation Parameter list.
Select Estimated Processing Time from the Workload Distribution Parameter list.
116
13 Click Perform Analysis. The report and graph display.
117
The eight queries lie in the last bucket (bucket 10 with a range of 142.20 - 158.00) are long
queries. However, another eight queries in the first bucket (bucket 1 with a range of 0.0015.80) are short running queries, with a wide gap show in bucket 2 through bucket 9.
The goal from the start of this process is to isolate long running requests found within the
ADW-DS workload, and apply different workload management to them. By adding the
last bucket to the ADW_Outliers workload, the necessary workload definition is achieved
to apply those different workload management techniques.
14 Right-click over Bucket 10, and select Add Estimated Processing Time clusters for deeper
analysis. Override the Min Estimated Processing Time to 30 seconds, and override the
Max Estimated Processing Time to 999999 seconds (basically unlimited).
The very short running requests relegated back to the original WD-ADW-DS workload.
118
after drill-down 2nd "add to"
ADWTACT
8%
ADWOutliers
17.4%
ADW-DS
74.6%
2514A027
In summary, the workload classifications within this example result in WD-ADW-DS
remain in its original state. To view, click Attributes under the WD-ADW-DS workload in
the Candidate Workloads Tree, then click on the Classification tab.
The workload WD-ADW-Outliers is created with a higher evaluation order than workload
WD-ADW-DS. To view, click Attributes for WD-ADW-Outliers, then click the Classification
tab.
119
For more information about evaluation order, see “Viewing Evaluation Order of
Candidate Workloads” on page 172.
Example 3: Workload Analysis for Utility Management
This example describes cluster analyses on utility types for workload definition classifications.
Example of workload analysis for utility management
120
1
Select Analysis>New Workload Recommendations. The Define DBQL Inputs dialog box
appears.
2
Inputs” on page 52.
3
In the Category box, select Users, and click OK. The Unassigned requests report displays.
4
Right-click over each workload and select Auto-Generate Workloads. The Candidate
Workload Report displays.
5
Right-click over WD-PriorityUsers, and select Analyze. The Analyze Workload window
appears.
121
The numbers adjacent to each option in the Workload Correlation Parameter and Workload
Distribution Parameter lists of the Refine Workload Classification pane show the total
numbers of elements used for correlation. (Utility types for distribution classification
parameters include min and max values.)
For example, Utility Type (5) indicates that there are five utility types available in DBQL for
analysis.
Cluster analysis on utility types collects all utilities that ran during the DBQL data
collection time interval.
The results of many queries executed during the query session are grouped under “ALL
OTHERS” clusters in the Analyze Workload tab for reporting purposes. (Workload
definitions, however, cannot be created from “ALL OTHERS” clusters.)
122
6
7
All non-Teradata Database utilities are grouped in the “Non-TD utilities” cluster. For
workload analysis of non-Teradata Database utilities:
•
A DBA can create a workload definition from the “Non-TD utilities” cluster or
combine this cluster with other Teradata Database utilities.
•
Workload definition classification for “Non-TD utilities” should be one of the
following:
•
Non-TD FastLoad
•
Non-TD Multiload
•
Non-TD FastExport = 0x200000 | 0x400000 | 0x800000
For workload analysis using Teradata Data utilities:
•
A DBA can create a workload definition by selecting one or more utilities from a
correlation report.
•
The following bitmap values represent the supported utility types for Release 14.10:
•
0x000002 = Include if standalone FastLoad
•
0x000004 = Include if standalone Multiload
•
0x000008 = Include if standalone FastExport
•
0x000010 = Include if ARC
•
0x000020 = Include if TPT FastLoad (load operator)
•
0x000040 = Include if TPT Multiload (update operator)
•
0x000080 = Include if TPT FastExport (export operator)
•
0x000100 = Include if CSP Save Dump FastLoad
•
0x000200 = Include if JDBC FastLoad
•
0x000400 = Include if JDBC Multiload
123
•
0x000800 = Include if JDBC FastExport
•
0x020000 = Include if generic 3rd party FastLoad
•
0x040000 = Include if generic 3rd party Multiload
•
0x080000 = Include if generic 3rd party FastExport
•
0x200000 = Include if non-TD FastLoad
•
0x400000 = Include if non-TD Multiload
•
0x800000 = Include if non-TD FastExport
•
0x1000000 = Include if BAR
If the DBA selects utility types StandaloneFastLoad, StandaloneMultiLoad and
StandaloneFastExport clusters to split into new workloads, then OR bit operations for
their bitmap values are saved in the TDWM database for classification as follows:
Classify Criteria WD_LoadUtilities: FastLoad OR MultiLoad OR FastExport = 0x000002 |
0x000004 | 0x000008
The classification page should be updated to include multiple utility types for WD
classification.
124
8
Click 'Attributes' under WD-PriorityUsers on the workload tree.
9
From the Classification tab, select Load Utility Type from the Criteria #2 drop-down list.
10 Click Choose from the AND pane. The Classify By Utility Types dialog box appears showing
the types of utilities to be used for classification.
11 Click OK to continue.
The Analyze Workload tab refreshes, displaying the results of the query.
125
The DBA can generate distribution analysis reports based on WHAT parameters and then
drill down the distribution report using the Zoom-in/Zoom-out features. The DBA
cannot, however, create workload definitions from distribution analysis reports. The query
estimate criteria (WHAT) cannot be used for utility type workload classifications.
Exclusion criteria is not allowed for workload definitions created using utility type
classifications, and the Exclusion page is read-only for all workloads defined using utility
types. Workloads created from utility types can be drilled down using WHO and WHERE
(database, table, and view only) parameters, and the result can be split into new
workloads. The following additional classification criteria can be used for utility type
workloads: accounts, user IDs, client addresses, client IDs, query bands and database
objects, including databases, tables, views, and so on.
126
CHAPTER 5
Analyzing Existing Workloads to Meet
SLGs
This section describes the theory and process of analyzing the existing workloads on the
system to determine if they meet the established Service Level Goals. It includes the following:
•
Existing Workload Analysis
•
Further Analysis for Workloads
•
Enhancing the Existing Workload Analysis Process
•
Starting Existing Workload Analysis
•
Viewing or Modifying SLGs
•
Splitting and Merging Workloads for Analysis
Existing Workload Analysis
When the actual response time characteristics are off by a specific percentage from the defined
service level goals calculated at the time of workload creation, an “X” in the SLG Met column
indicates that service level goals are not met. A percent variance displays for further analysis
with a visual indication against the workload. The SLG Met value calculations are based on the
actual workloads data logged in DBQLogtabl and TDWMSummaryLog tables after activation
of the rule set.
Note: SLG Met details display in the Candidate Workloads Report dialog box.
The following analyses can be done for workloads that have not met their service level goals:
•
Existing Workload Analysis - further analyzing and refining of the workload by selecting
analysis parameters and accepting the new recommended workload.
•
Recalculating the service level goals and applying the actual SLG values in a rule set.
•
Merging the workload and recalculating the SLG Met values.
•
Splitting the workload and adding or deleting classifications manually.
Further Analysis for Workloads
When a workload is selected for further analysis:
•
Each record in the log is mapped to classification criteria, along with a workload ID. A set
of records is obtained for each classification criteria for a specific workload, including the
workload ID condition.
127
Chapter 5: Analyzing Existing Workloads to Meet SLGs
•
The response time characteristics of these sets of records are compared against the service
level goals defined for the workload (goal service level goals), and the comparison status is
indicated.
•
Existing workloads that have similar response time characteristics may be grouped into a
new workload with new service level goals (or the service level goals of the current
workload can be modified, if all the classifications are not meeting the service level goals).
•
Records are analyzed for further classification (by identifying clusters on an uncovered
classification parameter) if the standard deviation is high for a classification, or if the CPU
usage is high.
Enhancing the Existing Workload Analysis Process
The following suggestions may help Teradata WA enhance the processing speed and accuracy
of the existing workload analysis process:
•
Select the appropriate DBQL log data for analysis (activated rule set data).
•
Verify that the TDWM database has sufficient spool space to create temporary tables for
analysis and service level goal calculations. Sufficient spool space is a primary requirement
for better performance during the calculation of service level goals and workload
refinement. If there is inadequate spool space, Teradata WA displays an error message and
service level goal calculation continues on actual DBQL tables, using multi-threading.
The new workload analysis process begins with defining the DBQL inputs for existing
workloads.
Defining Existing Workload DBQL Inputs
To define existing workload DBQL inputs
1
•
Click
•
Select Analysis > Existing Workload Analysis.
•
Press Ctrl+E.
128
2
Fill in the fields as described in the following table:
Option
Description
Log Option
• DBQL (this is the default)
• External DBQL
Click the ... button to load the database choices into
the selection box, then select the database.
External DBQL contains DBQL data that has been
129
Option
Description
Date Range
In the appropriate boxes, enter the starting date (From)
and ending date (To) of the range of the data collected.
The displayed date format depends on the regional
settings of the PC. To select a date from a calendar popup window, click the drop-down arrow. The default end
date is one day prior to the current system date; the
default start date is one week (7 days) prior to the default
end date.
Time
Select this option to specify a time window of less than 24
hours.
In the appropriate boxes, enter the starting and ending
times of the range in HH:MM:SS format, using a 24hour clock. The default start time is 00:00:00 (12:00
A.M.) and the default end time is 23:59:59 (11:59:59
P.M.).
To select a time that spans midnight, select a start time
greater than the end time.
23:59:59.99.
Filter within Range
Select this option to filter the returned data by days of the
week and times of day. When selected, the Every Day and
24 Hours checkboxes become enabled and selected.
Every Day
described in the previous row of this table, the Every Day
check box becomes enabled and selected. If left in that
condition, returned data will be captured in the database
every day of the week.
Clear the Every Day check box to select specific days of
the week to exclude from data capture.
When the Every Day check box is cleared, all options in
the Day of Week pane are enabled and selected. Clear one
or more of the check boxes for options Sunday, Monday,
Tuesday, Wednesday, Thursday, Friday, and Saturday to
exclude data capture on those days of the week.
130
Option
Description
24 Hours
described earlier in this table, the 24 Hours check box
becomes enabled and selected. If left in that condition,
returned data will be captured in the database 24 hours
per day for each day selected for capture as specified by
the Every Day option.
Clear the 24 Hours check box to specify a time window of
less than 24 hours during which data will be captured.
In the appropriate boxes under Time of Day, enter the
start time (From) and end time (To) in HH:MM:SS
format, using a 24-hour clock. The default start time is
00:00:00 (12:00 A.M.) and the default end time is
23:59:59 (11:59:59 P.M.).
To select a time spanning midnight, select a start time
greater than the end time from the Time of Day box.
23:59:59.99.
Rule set
• Rule Set - If the rule set is not already entered, click
the ... button to load the rule set choices into the
selection box, then select a rule set.
• OpEnv - Select the operating environment for the rule
set.
Always - the system default operating environment.
Select All - selects all available operating
environments (OpEnvs) for the rule set.
• SysCon - Select the system condition for the rule set.
Normal - the default system condition, which displays
the health of the database.
Select All - selects all available system conditions
(SysCons) for the rule set.
3
After specifying the options, click OK. Teradata WA queries the DBQL.
Note: The query process may take several minutes.
Viewing Workloads Using the Candidate Workload Report
The Candidate Workload Report window displayed in Figure 19 is divided into two panels:
•
The left panel displays the selected workloads in the Workloads tree. After a split or merge,
the workloads tree is updated so that workloads appear according to their evaluation
order. See “Viewing Evaluation Order of Candidate Workloads” on page 172 for more
information.
131
•
The right panel displays the Workloads Report. This is a list available workloads.
For more information on how to navigate the options in the Candidate Workload report, see
“Chapter 4 Analyzing New Workloads to Meet SLGs” on page 49.
Figure 19: Candidate Workload Report for Existing Workloads
Table 15 describes the columns displayed in the Workload report.
Table 15: Displayed Columns in the Workload report
Column Name
Description
Workloads
The name of the workload
AMPs by this session
and writes) issued across all AMPs by this session
Query Count
The number of queries in this workload that completed
during this collection interval
Avg Est Processing Time
The average estimated processing time for this user
SLG Met Details
The number of time the SLG was met for this workload, the
goal percentage and actual percentage of SLG met, and
comments for this workload
SLG Met, Goal %, Actual %,
Remarks
132
Table 15: Displayed Columns in the Workload report (continued)
Column Name
Description
CPU Per Query (Seconds)
The minimum, average, standard deviation, 95th percentile,
and maximum CPU seconds per queries for this workload
Max
Response Time
Result Row Count
Disk I/O Per Query
CPU To Disk Ratio
Active AMPS
Spool Usage (Bytes)
CPU Skew (Percent)
I/O Skew (Percent)
result response time for this workload
result rows returned for this workload
disk I/O’s per query for this workload
CPU/Disk ratio for this workload
number of active AMPs for this workload
spool usage across all VProcs for this workload
AMP CPU skew for this workload
AMP I/O skew for this workload
The Service Level Goals (SLG) can be viewed in graph format, and the settings modified using
the SLG Recommendations Window.
To view or modify service-level goals
1
From left window of the Workload Report, expand the workload, and then click on the SLG
Graph icon.
The SLG Recommendations window appears.
133
Note: Alternatively, display the SLG Recommendations window by selecting Rule Set >
Workloads> Calculate SLGs from the Teradata WA menu.
2
In the SLG Recommendations window, view the default parameters and resulting service
level recommendations, along with the displayed chart. Change the options as described in
the following table.
Table 16: SLG Recommendations window
Option
Description
SLG Parameters
Displays the service parameters that can be viewed or modified
to generate SLG recommendations. Click Response Time (the
default), or Throughput as appropriate.
• this parameter appears as the horizontal axis of the chart
• the value of this parameter can be edited in the SLG
Recommendations table displayed beneath the chart; no other
options are available for editing.
immediately. Response Time or Throughput SLGs can be saved
in the TDWM database, not both.
OpEnv
Displays the available operating environments. Click an OpEnv
in the list box or accept Always as the default.
immediately.
134
Table 16: SLG Recommendations window (continued)
Option
Description
Start Date / End Date
Displays the DBQL date range depicted in the graph. This is in
YYYY-MM-DD format.
Set Manually
Allows modification of the recommended service levels. This
check box is unchecked by default.
SLG Recommendations
Changes the selected service parameter’s recommended value
(shown highlighted in white). No other values are available for
editing (shown shaded).
are displayed. The response time goal shown is the value that
would satisfy a 80% goal.
3
Service percent
recommendations. You can adjust this as appropriate.
Factor by
Modifies the SLG parameter, with a factor of 1 being the same as
today, 0.1 being 10 times faster than today, 10.0 being 10 times
slower than today.
When satisfied with the new values, click Apply.
Teradata WA workload classifications can be further customized by merging or splitting
workloads. The splitting and merging workload process is DBA-driven. Two or more
workloads can be merged into one workload. One workload can be split up into several
workloads. The service level goals for the resulting new workloads are recalculated and
modified.
For example, when two or more workloads require less system resources, but the workloads
are still needed for the active system period, these workloads can be merged into one workload
and set with different service level goals.
When a workload is consuming too many resources or is not meeting service level goals, the
workload can be split into one or more workloads and assigned different service level goals.
The Process of Merging Workloads
The process of merging workloads involves the following:
1
Merge the workload classifications of different criteria and remove any duplicate
classifications.
2
Assign the appropriate performance AG mapping for the resulting workload.
3
Calculate and/or recalculate the service level goals for the merged workload (which can be
accepted or modified service level goals from the SLG Graph window.)
135
4
Merge the workload classifications.
The merging process performs a union of classifications of all workloads selected for the
merge process. Any duplicates of the workload classifications values are removed.
Currently, in workload classification, all clusters can be either included or excluded. The same
rule is used for merging workloads. If the merge process comes across both exclude/include
classification criteria, it would unionize all the classification criteria and assign exclude/
include based on the criteria in the selected workloads. See Figure 20 for an example of
merging workloads together.
Figure 20: Example of two workloads merging
WD_A
Include TWA
Applications
Include TWA
Applications
Include Client 153.58.33.99,
Addresses
Include BTEQ
Applications
Exclude Cient IDs RD185023
Statement
ALL DDL DML Select
Type
Include TWA
Applications
WD_B
WD_A_MG (After Merge).
Include VECOMP
Applications
Include TWA,VECOMP
Applications
Include VECOMP
Applications
Include TWA,VECOMP
Applications
Addresses
Addresses 153.58.33.99
Include VECOMP
Applications
Include
Applications Not allowed
Include Cient IDs BK185002
Exclude Cient IDs Not allowed
Statement
ALL DDL DML Select
Type
Include VECOMP
Applications
Statement
Type
Not allowed
Include
Applications
Not allowed
Minimum 100
Estimate Final
Rows
Minimum 50
Estimate Final
Rows
Minimum 50
Estimate Final
Rows
Minimum 1000
Estimate Final
Rows
Minimum 5000
Estimate Final
Rows
Minimum 5000
Estimate Final
Rows
Include TWA
Applications
Include VECOMP
Applications
Include TWA, VECOMP
Applications
2514A006
The following workloads and classifications cannot be merged:
136
•
A workload with AMP Limits classification cannot be merged with a workload with Final
Row Count classification
•
A workload with Utility Type classification cannot be merged with a workload with
Estimated Row Count, Estimated Processing Time, AMP Limits, or Object Type
classifications.
To merge workloads
1
Select a workload from the left panel, under the Candidate Workloads tree, to begin the
merge process. The merge process allows merging of any and all available workloads
(except the Default and the Console Application workloads) into the selected workload.
2
Right-click on the selected workload to display the shortcut menu.
3
Click Merge.
The Merge Workloads dialog box appears.
The following table describes the dialog box controls.
Options
Description
Available Workloads
Lists all workloads available for merging. Default and console
workloads are not available for the merge process.
Selected Workloads
Lists the workloads selected for the merge process.
Add
Moves the selected workload from Available Workloads to
Selected Workloads
Remove
Removes the workload from Selected Workloads, placing it back
in Available Workloads.
Merge
Merges all workloads in Selected Workloads into one workload.
Cancel
Closes the Merge Workloads dialog box.
4
Click the workload in Available Workloads to be merged, then click Add. Up to two
workloads can be selected for merging. The workload(s) appears in the Selected
Workloads list.
5
Click Merge to complete the process.
The merged workload name is generated by taking the name of the selected workload and
suffixing an _MG to the name. The workload name can be changed using the Rename option
from the shortcut menu after the merge process is completed and a new merged workload is
created.
137
Splitting Workloads
Splitting a workload breaks it into one or more separate workloads recursively, creating new
workloads from the existing workload classifications.
To split workloads
1
From the Candidate Workloads tree, right-click on the workload you want to split.
The shortcut menu displays.
2
Select Split.
The Split Workloads dialog box appears.
The following table describes the Split Workloads dialog box options.
138
Options
Description
Workload #1
Displays the source workload name. Below the name is its
classification.
Include
Lists the classifications to be included before splitting the
workload. Select the check box of the item to be included for the
split.
Options
Description
Exclude
Lists the classifications to be excluded before splitting the
workload. Select the check box of the item to be excluded for the
split. The exclusion limits the split to requests that include the
excluded object type. For more information, see “Classifying by
Excluded Objects for Splitting and Merging Workloads” on
page 142.
Note: If Teradata WA 14.10 is connected to Teradata Database
12.00, the Include or Exclude options can be used for each
classification type. If the system is connected to Teradata
Database 14.10, 14.0, 13.10, or 13.00, both Include and Exclude
options can be used for each classification type.
3
Workload #2: (Evaluated
First)
Displays the destination workload name. The destination
workload name is created by adding the suffix _SP1 to the source
workload name. Below the name is its classification.
Add New Classification
Creates a new workload classification.
Split
Splits the source workload. The source workload’s classification
is modified and a new split workload displays on the right panel.
Advanced
Activates the Copy, Move and Remove options.
Copy
Copies the selected classification criteria items from the source
workload to the split workload.
Move
Moves selected items from the source workload to the split
workload destination tree.
Remove
Removes the selected classification items from the split workload
classification tree and move them back to the source workload
tree.
Accept
Saves the changes and closes the Split Workloads dialog box.
Cancel
Discards the changes and closes the Split Workloads dialog box.
To add a new classification, click Add New Classification.
The Add Workload Classification dialog box appears.
4
Select the Choose another selection criteria check box. The --AND-- pane of the Add
Workload Classification dialog box appears.
5
Select a criteria from the drop-down list. The Choose button appears for you to further
refine the new classification criteria.
139
The following table describes Add Workload Classification dialog box options.
6
Options
Description
Criteria #1
Selects the classification criteria
Includes
Displays the selected objects within the chosen criteria
Choose
Allows inclusion and exclusion of strings within the chosen
criteria
Choose Another Selection
Criteria
Adds another classification criteria, with its own pull-down and
object list
Show
Creates a report of the classification criteria that may be saved
and/or printed
Restore
Undoes changes to the classification criteria
OK
Applies the classification changes
Cancel
Discards all changes and closes the dialog box
To include or exclude strings within the chosen criteria, click Choose.
The Classify By... dialog box appears.
140
The following table describes the Classify By... dialog box options.
Options
Description
Include
Includes the selected strings in the classification criteria.
Exclude
Excludes the selected strings from the classification criteria.
Load
Populates the Available classification strings list.
Available
Displays the available classification strings. If this list appears
empty, click Load to populate it.
Add
Moves the highlighted classification string to Selected status.
Remove
Removes the highlighted classification string from Selected
status.
OK
Applies the classification changes.
Cancel
Discards all changes and closes the dialog box.
7
Click OK when satisfied with the Classify By... criteria and to exit the dialog box.
8
Click OK to exit the Add Workload Classifications dialog box.
Now the Split Workloads dialog box should appear.
141
9
From the source workload classification on the left panel, click the check boxes next to the
analysis parameter clusters to be included in the destination workload classification. Select
individual clusters or select all clusters at the analysis parameter hierarchy (by clicking the
ClientAddr check box to select all the clusters in that directory).
Each analysis parameter node (for example, UserName, AppID, and ClientAddr), contains
cluster data that is either on the Included list or the Excluded list. Either include all clusters
or exclude all clusters; it is not possible to do both.
10 Click Split.
The split workload is created and the existing source workload classification is modified.
The name of the newly split workload contains the source workload classification’s name,
suffixed with an SP1.
11 Click Accept to save the changes.
Classifying by Excluded Objects for Splitting and Merging Workloads
This section describes classification by excluded objects for split and merged workloads.
Teradata WA includes an option to limit object exclusion to only requests that include the
excluded object type. This option is helpful for “Where” parameters such as Stored Procedures
or Macros.
For example, a DBA classifies a request into a workload but only wants a Stored Procedure,
and not Stored Procedure ‘A.’ The DBA could specifically exclude non-stored procedure
requests to not classify into the workload. Additionally, only stored procedures NOT named
Stored Procedure ‘A’ classify to this workload.
For information about splitting workloads, see “To split workloads” on page 138.
For information about how to merge workloads, see “To merge workloads” on page 137.
Classification by Excluding Objects for Workload Splits
For example, in Figure 21, in Workload #2, Crash dumps is included, and Sys_Calendar is
excluded under UserName. SysAdmin is included under AccountString.
142
Figure 21: Split workload with excluded and included objects
Split Workloads
Workload #1:
Workload #2: (Evaluated 1st)
WD-test1
WD-test1_SP4
Workload Classification
User Name
Workload Classification
User Name
Split
Include
Include
Advanced
DBC
Crashdumps
Exclude
Exclude
Advanced
EXTUSER
Account String
Sys_Calendar
Account String
Copy - >
Include
Include
$H-DBC-MANAGER
SysAdmin
Exclude
Move - >
$h-remote-console-use
Sys_Calendar
< - Remove
Add New Classification
Accept
Cancel
2514A016
After the workload split, the Classification tab for the original workload (WD-test1) displays
the following classifications.
Figure 22: Classification tab for original workload after a split
Workload Attributes Classification Exception Service Level Goals Query Limits
Criteria #1:
Account String
Include:
$H-DBC-MANAGER
Exclude:
Choose...
Choose another selection criteria
--AND-Criteria #2:
DBC
Username
Exclude:
EXTUSER
Choose...
2514A013
Criteria #1 is Account String, and $H-DBC-MANAGER is included, while $H-remoteconsole-use and Sys_Calendar are excluded. Criteria #2 is Username, and DBC is included,
while EXTUSER is excluded.
143
The Classification tab for the split workload (WD-test1_sp4) displays the following
classifications.
Figure 23: Classification tab for split workload with excluded and included objects
Criteria #1:
Account String
Include:
SysAdmin
Choose...
--AND-Criteria #2:
Username
Include:
Crashdumps
Exclude:
Choose...
2514A014
Criteria #1 for the split workload is Account String. It includes SysAdmin. Criteria #2 for the
split workload is Username. It includes Crashdumps and excludes Sys_Calendar.
Classification by Excluding Objects for Workload Merges
After a workload is merged together, the Classification tab displays the included and excluded
objects in one list for each classification type.
In this example, WD-test1 and WD-test1_sp4 are merged together. The classification for this
merge displays on the Classification tab as the following:
144
Figure 24: Classification tab for merged workload
Criteria #1:
Account String
Include:
$H-DBC-MANAGER
SysAdmin
Choose...
--AND-Criteria #2:
Username
Include:
DBC
Exclude:
EXTUSER
Choose...
2514A015
145
146
CHAPTER 6
Viewing or Changing Workload Data
This section discusses options in Teradata WA that support viewing or modifying workload
recommendations and workload definitions. It includes the following:
•
Working with Workload Attributes
•
Viewing the Active Rule Set
•
Viewing the Candidate Workload Report
•
Viewing Evaluation Order of Candidate Workloads
After a workload is analyzed, you can view and modify details about the workload, such as
workload period and service level goals.
Note: Avoid modifying workload classifications using the following procedure with New
Workload Recommendations or Existing Workload Analysis as changes made on the tabbed
dialogs will not be reflected in the Workloads Report.
To view workload attributes
1
From the Candidate Workload Report window, click the + sign to the left of the workload
whose attributes you want to view. The candidate workload listing expands in the tree.
2
Click Attributes. The Workload Attributes window appears.
147
Chapter 6: Viewing or Changing Workload Data
3
Click the appropriate tab to view workload attributes, classifications, exceptions, service
level goals and query limits as described in Table 17.
Table 17: Workload Attribute descriptions
148
Tab
Option
Description
Workload
Attributes
Name
A name for the new WD. Although not required, typically these begin with the
prefix “WD-” for easy identification.
Description
A description identifying this WD.
Log Query Detail
Select this option to specify detailed logging of each query to DBQLogTbl.
Enforcement
Priority
•
•
•
•
Tactical - short queries with a fixed response-time requirement.
Priority - important queries that should get extra resources.
Normal - normal queries; this is the default.
Background - low-priority queries with no response-time requirement.
Table 17: Workload Attribute descriptions (continued)
Tab
Option
Description
Classification
Criteria #1
Selects the classification criteria.
Includes
Displays the selected objects within the chosen criteria
Choose
Allows inclusion and exclusion of strings within the chosen criteria.
Choose another
selection criteria
Adds another classification criteria, with its own pull-down and object list.
Accept
Accepts the changes made to the Classification tab.
Restore
Undoes changes to the classification criteria.
Show
Creates a report of the classification criteria that maybe saved and/or printed.
Maximum Rows
The maximum number of rows in a spool file or final result.
IO Count
The maximum number of disk I/Os performed on behalf of the query.
Spool Size
The maximum size of a spool file in B.
Blocked Time
The length of time the query is blocked by another query.
Elapsed Time
The length of time the query has been running.
Number of Amps
The number of AMPs that participate in the query.
Sum Over All
Nodes
The total amount of CPU time (in hundredths of seconds) the query consumes
over all nodes.
Tactical CPU
Usage Threshold
(per node)
The per-node threshold of CPU usage for tactical workloads that, when
exceeded, triggers exception handling.
Qualification
Time
The length of time the exception condition must persist before an action is
triggered (in seconds).
IO Skew
Based on the Qualification Time, the maximum difference in disk I/O Counts
between the least busy and most busy AMP.
CPU Skew
Based on the Qualification Time, the maximum difference in CPU consumption
(in seconds) between the least busy and the most busy AMP.
CPU millisec per
IO
Based on the Qualification time, the maximum ratio of CPU consumption to
disk I/O during the last exception interval.
IO Skew Percent
Based on the Qualification Time, the percentage difference in disk I/O Counts
between the least busy and the most busy AMP.
CPU Skew
Percent
Based on the Qualification Time, the percentage difference in CPU consumption
between the least busy and the most busy AMP.
Exception
149
Table 17: Workload Attribute descriptions (continued)
Tab
Service Level
Goals
Query Limits
Option
Description
Operating
Environment
Lists the operating environment that the workload is currently in. The default is
Always.
Response Time
A response-time value in hours, minutes, and seconds. This is the maximum
amount of time that you expect to be required for completion of this workload.
Service Percent
An integer value corresponding to the percentage of this workload which you
expect to meet the service-level criteria.
Arrival Rate per
hour
An integer value corresponding to the number of queries that you expect to be
received hourly.
Throughput per
hour
An integer value corresponding to the number of queries that you expect to be
executed hourly.
CPU seconds per
query
An integer value corresponding to the processor time (in seconds) that you
expect to be required for executing each query.
State
The current state of default or base.
Override Default
Select this option to override the default limit for each state specified. When you
select this option Unlimited is activated.
Unlimited
The default option when Override Default is selected.
Limit
Select this option to define a new limit.
Reject
Select this option to reject over-limit queries for a particular state, otherwise
over-limit queries are delayed.
Working with Workload Classification Criteria
Teradata Database detects classification criteria before executing queries. Classification criteria
identifies the “who,” “what,” and “where” of requests as a way of grouping them for better
control, to ensure resources are allocated as appropriate to your needs.
For example, to allocate more resources to requests originating from a particular department
in your company, your classification criteria might specify the application or account that
corresponds to those requests. Conversely, using classification criteria, you can isolate
workloads that you want to assign lower priorities.
You can choose up to six classification criteria. It is recommended that you select at least one
item from the “who” criteria; you can combine additional criteria in accord with the following
limitations.
150
•
You cannot select a classification type more than once.
•
You cannot combine a utility type with anything other than a “who” characteristic, so if
you pick a utility as criteria 2, criteria 3 must be a “who” criteria item. If your second
criteria item is a “what” or “where,” you cannot follow it with a utility.
If you do not specify classification attributes for a WD, Teradata WA will initially not place any
queries into that WD. However, you could use that WD as a lower-priority WD, for example,
when queries encounter run-time exceptions in their original WDs and are downgraded to a
lower priority WD.
Defining Classification Criteria #1
To define or modify classification criteria #1 for a WD
✔ The selection shown for Criteria #1 in the Classification tab of the Workload Attributes
window automatically appears based on the criteria selected when “Defining Existing
Workload DBQL Inputs” on page 128. For example, if you select Users for DBQL input
criteria, Username appears in the Criteria #1 field of the Classification tab.
Depending on the DBQL input selected, the following options populate the Criteria #1 list
box, identifying the “who” of the workload:
•
Account Name
Note: The Account Name criteria includes the names of accounts. PG information is
not included. For example, an Account Name criteria containing DBC-MANAGER
only affects accounts such as $H-DBC-MANAGER and $M-DBC-MANAGER.
•
Account String
•
Application
•
Client Address
151
Client Address can be specified using:
•
IPv4 address format, where XXX is the range 0 to 255 decimal:
XXX.XXX.XXX.XXX
•
Client ID (for logon)
•
Profile
•
Username
•
Include QueryBand and Exclude QueryBand
Defining or Modifying Classification Criteria #2 - 6
If you look closely at the Classification tab of the Workload Attributes window (see “Defining
Classification Criteria #1” on page 151), you’ll find that some of its options are not enabled. In
particular, you cannot use the tab to add more classification criteria.
Note: Workload classification criteria cannot be manually modified from the Classification
tab of the Workload Attributes window. You can, however, add more classification criteria
using the Split option as described in this topic.
To define or modify classification criteria #2-6 for a WD
1
To define or modify classification criteria # 2 to 6 for a workload candidate, right-click the
workload in the list on the left side of the Workload Attributes window.
2
Click Split from the right-click menu.
The Split Workloads dialog box appears. For details on the fields used for splitting
workloads, see “Splitting Workloads” on page 138.
3
Click Add New Classification. The Classification tab appears similar to the tab of the same
name on the Workload Attributes window, however all functionality is enabled.
4
Select the Choose another selection criteria check box. The --AND-- pane of the tab
becomes visible, showing the Criteria #2 drop-down list box.
The list includes the items shown as check boxes in the Category pane of the Define DBQL
Inputs dialog and the items described in Table 18.
152
Table 18: Classification Options for Criteria #2
Selected Item
Also select...
Data Objects
Data objects to include and exclude in the Classify by Data
Objects dialog box that appears after selecting Data Objects and
clicking the Choose button.
These data objects can be selected:
• database
• table
• view
• macro
• stored procedure
• function
• method
In the Classify by Data Object dialog box, select objects to
include or exclude, and select the type of object to add to the
criteria. Load the objects and choose the specific object by
selecting it and clicking the Add button. For more information,
see “Example: Classification by Data Object” on page 156.
Statement Type
The statement types you want by selecting the appropriate check
boxes.
Utility Type
The name of the utility (FastLoad, FastExport, MultiLoad, all
three, or Archive/Restore) that you want to control in the list
box.
Teradata WA utility rules apply to FastLoad, MultiLoad,
FastExport, TPT Load/Update/Export operator, JDBC FastLoad,
and ARCMAIN. Teradata WA classifies the first utility-specific
SQL request from a utility job into a WD. All subsequent
requests for the utility job run under the same WD (priority).
AMP Limits
The check box for Include single or few AMP queries only if
appropriate.
Note: Selecting this check box causes the workload to accept
only queries that are not all-AMP queries. If AMP Limits is
selected but this check box is left cleared, no AMP limit is
defined and an error message appears because the classification
data is missing for this criteria.
Row Count
Either the Minimum Rows or the Maximum Rows check box or
both and type the corresponding values as appropriate.
Final Row Count
Either the Minimum Final Rows or the Maximum Final Rows
check box or both, and type the corresponding values, as
appropriate.
Either the Minimum Time or Maximum Time by selecting the
appropriate check box and specifying the CPU limits for each.
You can specify CPU time in hundredths of a second (using the
format HHH:MM:SS.dd).
153
Table 18: Classification Options for Criteria #2 (continued)
Selected Item
Also select...
Join Type
Types of joins to include, including:
•
•
•
•
•
•
5
All Joins
No Joins
All Product Joins
No Product Joins
All Unconstrained Product Joins
No Unconstrained Product Joins
Select the desired classification criteria for the selected workload from the Criteria #2 dropdown list box. For examples of how to proceed, see the following:
•
“Example: Classification by Application” on page 155
•
“Example: Classification by Data Object” on page 156
•
“Example: Classification by Query Band” on page 157
6
To select a additional criteria for the selected workload, repeat step 4. You can specify a
total of six classification criteria.
7
When criteria selections are complete, click OK.
8
Select Show to display of a report of all WD classification settings.
The Classification Description dialog box appears showing all workload classification
criteria.
9
154
To close the dialog box, click OK. To save or print the information in the dialog box, click
Save or Print. The typical Windows Save or Print dialog box appears.
10 To view the information in the Classification Description dialog box in plain text, click
Plain Text.
The plain text version of the Classification Description dialog box appears.
11 The text version of the Classification Description dialog describes the classification criteria
in plain text. To save or print the information in the dialog box, click Save or Print. The
standard Windows Save or Print dialog box appears. To exit the dialog box without saving,
click OK.
Example: Classification by Application
To classify a workload by application
1
Follow the instructions from “Defining or Modifying Classification Criteria #2 - 6” on
page 152 and select Application from the Criteria #2 list of the Classification tab.
The Choose box and button become enabled.
2
Click Choose.
The Classify by Application dialog box appears.
3
Click Load to display all items that can be used as application attributes.
4
From the Available list, select the items you want to include as attributes and click Include.
Note: Use the SHIFT and CTRL keys to select multiple consecutive or non-consecutive
attributes. To move an attribute back to the Available list, select it and click Remove.
5
From the Available list, select the attributes to exclude and click Exclude.
6
When finished, click OK to return to the Classification tab and select additional criteria.
(Use Cancel to discard classification selections and start over.)
155
Example: Classification by Data Object
To classify a workload by data object
1
page 152 and select Data Objects from the Criteria #2 list of the Classification tab.
The Choose box and button become enabled.
2
Click Choose.
The Classify by Data Object dialog box appears.
156
3
From the Classify by Data Object dialog box, click Choose from the Object Type dropdown list, and then select the type of data object to be used for classification from one of
the following.
•
Database
•
Table
•
View
•
Macro
•
Stored Procedure
•
Function
•
Method
The Load button becomes enabled.
4
Click Load to display all items that can be used as attributes for the selected data object.
5
From the Available list, select the items you want to include as attributes and click Include.
Note: Use the SHIFT and CTRL keys to select multiple consecutive or non-consecutive
attributes. To move an attribute back to the Available list, select it and click Remove.
6
From the Available list, select the attributes to exclude and click Exclude.
7
When finished, click OK to return to the Classification tab and select additional criteria.
Use Cancel to discard classification selections and start over.
Example: Classification by Query Band
The Include QueryBand and Exclude QueryBand classification options enable requests coming
from a single or common logon to be classified into different workloads based on the query
band set by the originating application. This enables an application to influence different
priorities for different requests. For example, the GUI for an application may have dialogs that
require quick responses and other dialogs that submit long running reports that run in the
157
background. The application can set a different query band for each type of job, causing the
requests to be classified into different workloads and run at different priorities. Instead of
running the entire application in a single workload, the application can execute the requests in
different workloads, each with a different priority, enabling better use of system resources.
Query band values with the same name are OR’ed. Query band values with different names
are AND’ed.
(NameA=ValA1 OR …
OR NameA=ValAn ) AND
(NameB=ValB1 OR …
OR NameB=ValBm ) AND
…
(NameX=ValX1 OR …
OR NameX=ValXx )
For more on query band usage, see Teradata Viewpoint User Guide (B035-2206).
To classify a workload by query band
For this example, assume that a workload is being created for batch requisition types by north
or east regions, but an exception is needed to exclude accounting jobs.
1
page 152 and select Include QueryBand from the Criteria #2 list of the Classification tab.
2
Click Choose.
The Include QueryBand dialog box appears.
3
Select Load Names to display all query band names and for this example, select the
Region name. Alternatively, type the name Region in the QueryBand Names box.
4
Select Load Values to display all query band values, and for this example, select the North
values. Alternatively, type the value North in the QueryBand Values box.
5
Select Add to add the name and value pair.
6
Repeat steps 2-4 steps to add a name and value pair for the East region.
7
When finished, click OK to return to the Classification tab. Use Cancel to discard your
classification selections and start over.
8
Click the Choose another selection criteria check box.
The Criteria drop-down list appears for you to select the next criteria.
158
9
Select Exclude QueryBand. Notice that Include QueryBand is no longer an option.
The Exclude QueryBand dialog box appears.
10 Repeat the steps used to configure the Include QueryBand dialog box and define the
accounting job whose query band you want to exclude.
11 When finished, select OK to close the dialog box and return to the Classification tab, which
appears similar to the following.
Working with Workload Exceptions
Setting Run-Time Exception Directives
After you create new WDs, you define exception directives that instruct Teradata WA how to
monitor queries, and what to do if a query exceeds exception criteria while it is executing.
An exception directive consists of a set of exception criteria (exception metrics) and a set of
exception actions (actions that Teradata WA takes when all of the metrics for a set of exception
criteria are exceeded). If a request exceeds all exception metrics (for example, a request
exceeds 1000 CPU seconds), it is potentially disqualified from the workload and conforms to
the enabled exception actions.
When specifying multiple metrics in one exception criteria set for a WD, they act as a set of
AND'ed conditions.
Multiple exception directives can be defined for a WD. When you define multiple exception
directives for a WD with different sets of exception criteria but the same set of exception
159
actions, each exception criteria set is treated as alternative (OR'd) conditions. See “Handling
Concurrent Multiple Exception Directives for a WD” on page 169 for guidelines Teradata WA
follows when multiple exception directives are applicable at the same time for a WD.
It is recommended that you avoid overly complex combinations of exception criteria in an
exception directive until you have experience about how your system performs.
Exception directives are operating environment-dependent. You can vary exception directives
for different operating environments. In one operating environment, a WD may use several
exception directives, while in another operating environment the same WD may not use any
exception directives.
Note: You cannot specify exception directives for WDs that use utilities as classification
criteria.
Setting Local Exception Directives
You can use Teradata WA to define local exception directives for a WD. A local exception
directive applies only to the current WD. A global exception directive applies to several (or all)
WDs. For instructions on creating global exception directives, see Teradata Viewpoint User
Guide (B035-2206).
Note: Exception actions are unavailable if you selected a utility type in the Classification tab.
160
To create a new local exception directive for a WD
1
Select a WD and click the Exception tab. The Exception tab appears.
2
Click New. The Add Local Exception dialog box displays.
Figure 25: Add Local Exception Dialog Box
161
3
Fill in the fields/controls as follows.
Table 19: Add Local Exception Fields/Controls
Field/Control.
Action/Comment.
Exception Name
Enter the name of the new local exception.
Description
Specify an optional description.
Apply to Operating
Environment(s)
Apply the local exception to one or more operating environment
periods. By default, all operating environments are selected.
Note that you can select Overview in the Exception tab to view the
operating environment periods you selected for a local exception.
4
Select OK to close the dialog box and return to the Exception tab.
5
To specify exception criteria for the new exception directive, see “To define exception
criteria” on page 163.
6
To specify exception actions for the new exception directive, see “To define exception
actions” on page 166.
7
To apply operating environments to your new exception directive, select Apply OpEnv. The
Exception Apply dialog box displays with the defined operating environments. For
instructions on defining operating environments, see “Adding Initial Workload Periods for
PSA Migration” on page 25.
Figure 26: Sample Exception Apply Dialog Box
8
Select the operating environments you want to apply to the exception directive, and select
OK to close the dialog box.
9
Select Accept to save your settings, Restore to reverse them
Select Overview to view the operating environments you applied to the exception directive.
162
To delete exceptions
1
From the Exception tab, select the exception you want to delete, and then click Delete. The
Exception Delete dialog box appears showing the selected exception.
2
Click OK.
To define exception criteria
1
Select the exception directive you want to define in the Exceptions tab.
2
Fill in the fields/controls as follows.
Table 20: Exception Criteria Fields/Controls
Field/Control
Action/Comment
Maximum Rows
1 Select the control.
2 Enter the per step maximum rows in a spool file.
IO Count
2 Enter the maximum number of disk I/Os performed on behalf of
the query.
Spool Size
2 Enter the maximum size of a spool file (per step).
3 Choose whether the size is in:
•
•
•
•
Number of Amps
Bytes
Thousand Bytes
Million Bytes
Billion Bytes
2 Enter the number of AMPs that participate in the query.
Blocked Time
2 Enter the length of time the query is blocked by another query.
Elapsed Time
2 Enter the length of time the query has been running (that is,
response time).
This time is stored in the Teradata Database as centiseconds.
Sum Over All Nodes
2 Enter the total amount of CPU time consumed by the query over
all nodes.
163
Table 20: Exception Criteria Fields/Controls (continued)
Field/Control
Action/Comment
Tactical CPU Usage
Threshold (per node)
2 Enter a positive value. Note the following:
• Specify a value less than the value specified for Sum Over All
Nodes.
• Specify a value less than 3 seconds to optimize performance.
• Specify Change Workload and another WD mapped to an AG
in the same RP as one of the exception actions.
For more information on setting this control, see Teradata
Viewpoint User Guide (B035-2206).
Note the following:
• This parameter is enabled only if the WD is Tactical in the
Workload Attributes tab and there is a positive value for CPU Sum
Over All Nodes.
• All exceptions in the same operating environment with Tactical
CPU Usage Threshold (per node) must use the same value and
have the same WD in a Change Workload exception action.
Qualification CPU Time
1 Select the control. The Qualification Time box becomes active
when a skew control is checked.
2 Enter the length of time the following exception conditions must
persist before the following criteria are satisfied (in CPU
seconds):
• CPU millisec per IO
• IO Skew
• CPU Skew
• IO Skew Percent
• CPU Skew Percent
You must select one of these criteria to activate Qualification Time.
Note that if you do not enter a Qualification Time value, Teradata
WA uses the Exception Interval.
Qualification Time must be an integer multiple of the global the
Exception Interval and greater than zero. For more information on
these options, see Teradata Viewpoint User Guide (B035-2206).
164
Field/Control
Action/Comment
IO Skew
CPU Skew
2 Enter a value:
• IO Skew: The maximum difference in disk I/O counts between
the busiest AMP and the average of all involved AMPs during
the last exception interval.
• CPU Skew: The maximum difference in CPU consumption
between the busiest AMP and the average of all involved
AMPs during the last exception interval.
A value of zero means there is no skew. A value greater than
zero indicates skew that accumulates to a larger and larger
value as long as the skew continues, up until the skew exceeds
the Qualification Time.
For more information on these options, see Teradata Viewpoint User
Guide (B035-2206).
Note the following:
• The skew must exceed the Qualification Time before Teradata WA
performs the action you specify.
• The skew must persist for a specifiable length of time, in CPU
seconds, that is greater than one global Exception Interval, to
qualify as an exception.
CPU millisec per IO
2 Enter the maximum ratio of CPU consumption to disk I/O
during the last exception interval.
You can use this control to detect queries that have an unusually
high ratio of CPU processing relative to logical I/Os incurred (for
example, an accidental unconstrained product join performed on
a very large table). Because of their very high CPU usage, these
queries can steal CPU resources from other higher priority
workloads, impacting the ability of the Priority Scheduler to
favor higher priority requests.
It is recommended that you initially set this control to 5 or
greater.
You must select this control to activate Qualification Time.
Note the following:
• The ratio must exceed the Qualification Time before Teradata WA
• The ratio must persist for a specifiable length of time, in CPU
seconds, that is greater than one global Exception Interval, to
qualify as an exception.
165
Field/Control
Action/Comment
IO Skew Percent
CPU Skew Percent
2 Enter a value:
• IO Skew Percent: The maximum percentage difference in disk
I/O counts between the busiest AMP and the average of all
involved AMPs during the last exception interval.
• CPU Skew Percent: The maximum percentage difference in
CPU consumption between the busiest AMP and the average
of all involved AMPs during the last exception interval.
A value of 0% means there is no skew. A value greater than 0%
indicates skew. The larger the percentage, the worse the skew
is. The impact of that skew grows exponentially.
The skew must exceed the Qualification Time before Teradata WA
For more information about these options, see Teradata Viewpoint
User Guide (B035-2206).
3
Select Accept to accept your changes.
4
Next, specify the exception actions Teradata WA performs when the exception criteria are
exceeded.
To define exception actions
✔ Under Exception Actions, select the appropriate fields/controls. You must specify at least
one exception criteria to access these controls.
Table 21: Exception Action Fields/Controls
Field/Control
Action/Comment
No Exception Monitoring
Select this control to prevent logging.
This control temporarily disables the exception directive without
deleting it.
Continue and Log
Select this control to log the exception and choose another action.
If you select this option, you can select Change Workload, Raise
Alert, and Run Program.
166
Table 21: Exception Action Fields/Controls (continued)
Field/Control
Action/Comment
Change Workload
1 Select Continue and Log.
Change Workload is only available with Continue and Log.
2 Select Change Workload.
3 Select the WD in the list box to log the exception and move the
request to the specified WD.
If you specify a positive value for Tactical CPU Usage Threshold
(per node), you must specify Change Workload and another WD
mapped to an AG in the same RP as one of the exception
actions.
All exceptions in the same operating environment with Tactical
CPU Usage Threshold (per node) must use the same value and have
the same WD in a Change Workload exception action.
If you specified values for Blocked Time, Elapsed Time, or both,
Change Workload is not an option as an exception action.
When specifying Change Workload as the exception action that is
not to be applied to all operating environments, the following
warning will display:
Warning: By not applying an Exception with a Change Workload
action to all operating Environments, a request may not
consistently route to the same final Workload across
different Operating Environments. This may lead to
misleading or confusing workload accounting.
You may not specify Change Workload for the default workload
(WD-default).
Raise Alert
1 Select Continue and Log, Abort and Log, or Abort on Select and
Log to access Raise Alert.
2 Select Raise Alert to log the exception and raise an alert.
3 Enter the name of the alert configured using Teradata
Viewpoint Alert Setup.
Run Program
Log to access Run Program.
2 Select Run Program to log the exception and run a program.
For more information, see Teradata Viewpoint User Guide
(B035-2206).
Post to Queue Table
Log to access Post to Queue Table.
2 Select Post to Queue Table to log to the DBC.SystemQtbl table.
Note that the Query ID is recorded and can be used to connect
information from the TDWMExceptionLog and the
DBQLSqlTbl.
3 [Optional] Enter a comment (maximum 120 characters) in the
text box.
167
Table 21: Exception Action Fields/Controls (continued)
Field/Control
Action/Comment
Abort and Log
Select this control to log the exception and abort the request.
When you select this option, Raise Alert and Run Program are
enabled.
Abort on Select and Log
Select this control to log the exception and abort the request if it
contains only SELECT statement(s) and the current transaction
has not executed any UPDATE, DELETE, or INSERT statements.
Otherwise, select Continue and Log.
When you select this option, Raise Alert and Run Program are
enabled.
Setting Exception Precedence
After you define two or more local or global exception directives, you can set the precedence.
Teradata WA uses the precedence to determine the exception directives that are more
important to honor in the event of a conflict.
Teradata WA typically honors local exception directives before global exception directives.
Note that Teradata WA does not consider precedence when evaluating exception directives.
Teradata WA only considers precedence when performing the actions you specified.
To set exception precedence
1
168
On the Exception tab for a WD, or in the Global Exceptions view, select Precedence. The
Exception Precedence dialog box displays.
The Exception Precedence dialog box lists all exceptions defined for a workload, and
indicates their priority in descending order. By default, the exceptions are listed in the
order in which they are created.
2
To change the priority of an exception, select the exception, and then select the up or down
arrow to move it to its desired location. Repeat this step for each exception whose priority
you want to change.
3
When finished, select OK to accept the priority listing and close the dialog box.
Handling Concurrent Multiple Exception Directives for a WD
Teradata WA follows these guidelines when multiple exception directives (multiple exception
criteria/actions) are applicable at the same time for a WD.
Teradata WA evaluates all exception directives. It is possible that multiple exception directives
are exceeded together. If so, Teradata WA performs all the corresponding exception actions
that do not conflict.
A conflict occurs when two exception actions to be performed are either:
•
Abort and change WD or
•
Change to different WDs (for example, change to WD-A and change to WD-B).
Teradata WA follows these guidelines to resolve conflicting exception actions when necessary:
•
Local exception actions take precedence over global exception actions.
•
Teradata WA orders local and global exception actions to their defined precedence for
resolving situations similar to the following case:
if Maximum Rows > 100, Change Workload to WD-M
if Sum Over All Nodes > 200, Change Workload to WD-N
If Maximum Rows and Sum Over All Nodes both exceed their limits at the same time, the
defined precedence determines to which WD Teradata WA changes.
•
If Teradata WA must perform several exception actions because one or more exception
criteria occur simultaneously, Teradata WA always executes all Raise Alert, Run Program,
and Post to Queue Table exception actions. Other actions occur as follows:
•
If you did not specify Abort and Log or Abort on Select and Log, and you specified
multiple global Change Workload exception actions, the global Change Workload
exception action with highest precedence occurs. Teradata WA logs all other Change
Workload exception actions as overridden.
•
multiple local Change Workload exception actions, the local Change Workload
exception action with highest precedence occurs. Teradata WA logs all other Change
•
multiple global and local Change Workload exception actions, the local Change
Workload exception action with highest precedence occurs, since local exception
actions take precedence over global exception actions. Teradata WA logs all other
Change Workload exception actions as overridden.
169
•
Aborts take precedence over any Change Workload exception actions. If you specified
Abort and Log or Abort on Select and Log, and you specified multiple global and local
Change Workload exception actions, Teradata WA aborts the query and logs all Change
The Active Rule Set Information screen displays the name and historical information about
the rule set.
Note: This screen is not available during New Workload Recommendations and Existing
Workload Analysis processes.
To display active rule sets
✔ After starting Workload Analyzer, select View > Active Rule Set.
The Active Rule Set Information dialog box appears.
Note: This dialog box cannot be used to change rule set information.
The Candidate Workload Report contains classification criteria, service level goals and other
important information about candidate workloads.
To view a Candidate Workload Report
1
After connecting to the TDWM database, select Analysis > New Workload
Recommendations.
170
2
Complete the parameters as described in “Defining DBQL Inputs” on page 52.
3
After specifying the options, click OK. Teradata WA queries the DBQL. This query may
take several minutes.
171
To change information displayed in the summary, use the Attributes or SLG Graph
options as appropriate; these are in the left pane of the Teradata WA user interface.
Note: For detailed information on the Workload Report options, see “Viewing Workloads
Using the Candidate Workload Report” on page 56.
Viewing Evaluation Order of Candidate
Workloads
Teradata WA sets the evaluation order of workloads in the Candidate Workloads tree after
every workload split or merge. The execution of queries can be determined for workloads for
classification overlapping.
The following table describes how evaluation order is determined for workloads in the
Candidate Workload tree.
Table 22: Examples of workloads and evaluation order
Example
Description
Evaluation Order
1
A workload such as WD-TWA (a parent
workload - Account=TWA and evaluation order
of 5) is analyzed with the correlation parameter
UserID (TDWM).
WD-TWA is set at a higher evaluation order
because of the parent workload (WD-TWA)
WD-TWA is split into a new workload (WDTDWM).
172
WD-TDWM-classification (Account=TWA and
UserID=TDWM). The evaluation order is five.
WD-TWA-classification (Account=TWA). The
evaluation order is six.
Table 22: Examples of workloads and evaluation order (continued)
Example
Description
Evaluation Order
2
WD-TDWM is split into a new workload with
Estimated Processing Time as its distribution
parameter.
WD-TDWM-Estimated Processing Timeclassification (Account=TWA and
UserID=TDWM and Estimated Processing
Time>10 seconds). The evaluation order is five.
WD-TDWM-classification (Account=TWA and
UserID=TDWM). The evaluation order is six.
WD-TWA-classification (Account=TWA). The
evaluation order is seven.
3
The workload in Example1 is split using Copy
and Move.
Evaluation order results are the same as Example
1.
4
The workload in Example 1 with a wild card.
The parent workload of a wild card workload
will always have a higher evaluation order.
5
For workload merging, Teradata WA sets the
same target workload evaluation order (the
workloads to be merged) as the merged
workload.
WD-A (Account=A). Evaluation order is ten.
WD-B (Account=B). Evaluation order is 11.
WD-A-Estimated Processing Time (Account=A
and Estimated Processing Time>10 seconds).
The evaluation order is 12.
WD-A and WD-B are merged with WD-AEstimated Processing Time (target workload).
WD-Merge1 (Account in (A,B) and Estimated
Processint Time>10 seconds). The evaluation
order is 12.
173
174
CHAPTER 7
Changes to support TASM 14.10 SLG
Responsive Priority Scheduler
This section discusses the Teradata Workload Analyzer interface changes added for TASM
14.10 and SLES11 support. It includes the following topics:
•
TASM 14.10 — SLES11 Support
•
Workload Attributes
•
Other GUI Changes for TASM SLES11 Support
Teradata 14.10 TASM includes a new Priority Scheduler design for SLES11.
The old Priority Scheduler is an application for TD 14.10 SLES10.
The Priority Scheduler for SLES11 is based on constructs such as Virtual Partitions, Workload
Methods, Access Levels, and Tiers.
All the features that exist in TWA 13.10 will work as is for TD 14.10/SLES10 (except 14.10
changes other than SLES11 Priority Scheduler).
Note the following changes when TWA 14.10 is connected to TD 14.10/SLES11:
•
The Analysis > Convert PDSets to Workloads menu item is disabled. This option is not
supported for TD 14.10/SLES11.
•
Four new default workloads exist in addition to the WD-Default workload. All four
default workloads are listed in the candidate workload tree window.
•
These Default workloads are created for Timeshare workload method with access rates
Top, High, Medium, and Low under the default Virtual Partition. Evaluation orders of
these Workloads are in the following order:
Table 23: Default TWA Workloads
Workload
Name
Workload
Classification
Workload Method
Timeshare Access
Level
WD-Top
Account = "$R*"
Timeshare
Top
WD-High
Account = "$H*"
Timeshare
High
WD-Medium
Account = "$M*"
Timeshare
Medium
175
Chapter 7: Changes to support TASM 14.10 SLG Responsive Priority Scheduler
Table 23: Default TWA Workloads (continued)
176
Workload
Name
Workload
Classification
Workload Method
Timeshare Access
Level
WD-Low
Account = "$L*"
Timeshare
Low
WD-Default
<no classification>
Timeshare
Medium
•
The RuleSet > Workload to AG mapping menu item is disabled since it is not applicable for
SLES11 Priority Scheduler.
•
The Workload Attributes tab view has changed. See “Workload Attributes” on page 177 for
more details.
•
A new tab has been added in the Workload Attributes tab view to define the Tactical
Exception for Tactical Workload method.
•
All Tactical Workloads have a default Tactical Exception rule pair (CPU per Node and I/O
per Node) set to default thresholds and are assigned a Change Workload action of WDDefault. The DBA can use the Tactical Exception workload attribute tab to change the
default setting.
•
TWA 14.10 creates a default Virtual Partition name “Standard” with a quota value of 100.
All the TWA recommended workloads are mapped with the default Virtual Partition. A
Virtual Partition other than the default can be created by selecting Viewpoint >Workload
Designer.
Workload Attributes
Workload Attributes
The default Workload Method is Timeshare with Medium access rate.
The DBA can select a Top, Medium, High, or Low access rate for the Timeshare workload
method.
The DBA has to enter percent share values for the SLG Tier workload method.
Workload Method:
•
Tactical: short queries with a fixed response-time requirement.
•
SLG Tier: important queries that should get extra resources.
•
Timeshare: normal queries. This is the default setting.
Tactical exception directive for a WD:
The Tactical Exception tab is enabled only for the Tactical workload method.
177
Field/Control
Action/Comment
Exception Name
Enter the name of the tactical exception
Description
Specify an optional description
CPU Time
Enter the CPU Time value
Tactical CPU Per Node
Enter the CPU Per Node value
IO Physical
Enter the IO Physical space value
IO Per Node
Enter the IO Per Node value
The Add Workload dialog has changed:
178
When Split to New Workload with (selected Distribution Parameter) as Exception is selected, the
Add New workload With Exception dialog box displays.
179
180
CHAPTER 8
Recommendation for SLG Tier and
Workload Percentage
The Teradata 14.10 Priority Scheduler uses different approaches to prioritization in Linux
SLES 10 and SLES 11. As a result, workloads designed under SLES 10 need to be adjusted to
achieve similar results under SLES 11.
The SLG Tier Hints Report
The TASM PreMigration tool helps customers to migrate an existing workload to Tactical and
TimeShare methods based on enforcement priority and relative weights.
The SLG Tier method is intended for workloads that are associated with a short service level
goal or service level expectation, which do not generally consume large amounts of CPU, and
whose response time consistency is critical to the business.
The PreMigration recommendation on SLG Tier mapping is based on enforcement priority
and workload classification - which may not be correct for many customers. PreMigration
does not provide any recommendation for SLG Tier workload method percent share. This
complicates SLES11 TASM migration.
Many customers find it difficult to assign the workloads to the SLG Tier method with an
appropriate percent share. TWA bypasses this difficulty by providing the option to analyze the
existing workloads based on DBQL data, and in this way provides the recommendations for
workload reconfiguration.
This TWA feature analyzes the existing workloads and provides the recommendations for SLG
Tier migration based on peak CPU time and workload relative weight.
The Existing Workload Analysis feature analyzes the DBQL data based on the rules shown in
“Figure 27: Existing Workload Analysis Rules” on page 182 and provides the
recommendations for the SLG Tier workload management method and the workload percent
share. For more information on using Existing Workload Analysis, see “Chapter 5 Analyzing
Existing Workloads to Meet SLGs” on page 127.
181
Chapter 8: Recommendation for SLG Tier and Workload Percentage
Figure 27: Existing Workload Analysis Rules
To generate an SLG Tier Hints Report
✔ In the Existing workload Candidates Workload Report, right-click a workload and select
SLG tier hints Report to generate the recommendations as shown below.
182
The SLG Tier Workload Method Hints Report appears.
Figure 28: SLG Tier Workload Method Hints Report
Field
Description
Workload Name
Displays the name of the current workload being viewed
Displays the currently assigned enforcement priority for the selected
workload
Relative Weight %
Displays the relative weight associated with the workload
Peak CPU %
Displays percent of Total CPU Percentage of the total CPU time (in
seconds) used on all AMPs by this session
SLG (Response Time)
Displays SLG Changes Response Time
183
184
Field
Description
Recommendation for
SLG Tier
Displays recommendation for SLG tiers (YES/NO)
Recommended SLG
Tier Share
Displays recommended Share Percentage of SLG tier
Glossary
A
account The distinct account name portion of the system account strings, excluding the
performance group designation. Accounts can be employed wherever a user object can be
specified.
allocation group (AG) A set of parameters that determine the amount of resources available
to the sessions assigned to a PG referencing a specific AG. Has an assigned weight that is
compared to other AG weights. An AG can limit the total amount of CPU used by sessions
under its control.
C
CLI Command-line interface
CLIv2 Call-Level Interface, Version 2. A library of routines that enable an application
program to access data stored in Teradata Database. When used with network-attached
clients, CLIv2 contains the following components:
•
CLI (Call-Level Interface)
•
MTDP (Micro Teradata Director Program)
•
MOSI (Micro Operating System Interface)
Version 2 of the CLI interface. A collection of callable service routines that provide an
interface to a Teradata Database. The interface between the application program and the
MTDP (for network-attached clients) or TDP (for mainframe-attached clients).
column In the relational model of Teradata SQL, databases consist of one or more tables. In
turn, each table consists of fields, organized into one or more columns by zero or more rows.
All of the fields of a given column share the same attributes.
CPU
Central processing unit
D
DBA Database Administrator. Generally, a person responsible for the design and
management of one or more databases and for the evaluation, selection, and implementation
of database management systems.
DBC Name of database with Teradata Database system tables.
DBCAREA A communication structure shared by an application program and CLI. The
application uses it to forward control and data information. CLI uses it to return control and
data information. An application may use a single DBCAREA or multiple DBCAREAs. CLI
185
Glossary
retains no knowledge of a particular DBCAREA across multiple CLI calls. CLI is concerned
only with the values for DBCAREA that are meaningful to the routine called.
DBQL Database Query Logging, Database Query Log DBQL is a series of system tables
created in the DBC database during Teradata Database installation. Used to track query
processing. See Database Administration (B035-1093) to learn more about the DBQL.
DBQM
Database Query Manager.
DDL Data Definition Language. Supports manipulating database structures and the Data
Dictionary information kept about these structures. In Teradata SQL, the statements and
facilities that manipulate database structures (such as CREATE, MODIFY, DROP, GRANT,
REVOKE, and GIVE) and the Data Dictionary information kept about those structures. In the
typical, pre-relational data management system, data definition and data manipulation
facilities are separated, and the data definition facilities are less flexible and more difficult to
use than in a relational system.
DML Data Manipulation Language In Teradata SQL, the statements and facilities that
manipulate or change the information content of the database. These statements include
SELECT, INSERT, UPDATE, and DELETE.
I
ID
Identifier or Identification.
J
JDBC Java Database Connectivity An API for the Java programming language that defines
how a client can access a database. Provides methods for querying and updating data in a
database. Oriented toward relational databases.
M
macro A file created and stored on Teradata Database and executed in response to a
Teradata SQL EXECUTE statement. A set of Teradata SQL statements stored by the Teradata
Database and executed by a single EXECUTE statement. Each macro execution is implicitly
treated as a transaction.
P
parameter A variable name in a macro for which an argument value is substituted when the
macro is executed.
PDSet Collection of data, including the resource partition, performance group, allocation
group, performance period type, and other definitions that control how the Priority Scheduler
manages and schedules session execution.
procedure Teradata stored procedure. Teradata provides SPL to create stored procedures. A
stored procedure contains SQL to access data from within Teradata and SPL to control the
execution of the SQL.
186
Glossary
Q
query management The primary function of DWM is to manage logons and queries. This
feature examines logon and query requests before they are dispatched for execution within
Teradata Database, and may reject logons, and may reject or delay queries. It does this by
comparing the objects referenced in the requests to the types of DBA-defined rules.
R
request
In host software, a message sent from an application program to Teradata Database.
resource partition A collection of prioritized PGs related by user associations. Has an
assigned weight that determines the proportion of resources available to that partition relative
to the other partitions defined for that Teradata Database.
rule Rules are the name given to the method used by DWM to define what requests are
prohibited from being immediately executed on Teradata Database. That is, the rules enforced
by DWM provide the Query Management capabilities.
resource partitions Resource partitions divide the Teradata Database users into groups
based on some use or priority strategy, such as by subject area or type of work.
S
session Also called a Teradata Database session. A session begins when the user logs on to
Teradata Database and ends when the user logs off Teradata Database. In client software, a
logical connection between an application program on a host and Teradata Database. The
connection permits the application program to send one request at a time to and receive one
response at a time from Teradata Database.
statement A request for processing by Teradata Database. A statement consists of a keyword
verb, optional phrases, and operands and is processed as a single entity.
SQL
Structured Query Language
T
table A set of one or more columns with zero or more rows that consist of fields of related
information. A two-dimensional structure made up of one or more columns with zero or
more rows that consist of fields of related information. See also target table.
TDWM
TASM
A database used with Teradata Workload Analyzer.
Teradata Active System Management
V
view An alternate way of organizing and presenting information in a Teradata Database. A
view, like a table, has rows and columns. However, the rows and columns of a view are not
187
Glossary
stored directly by Teradata Database. They are derived from the rows and columns of tables
(or other views) whenever the view is referenced.
188
Index
A
About command 32
about Teradata WA 15
Account field 41
Account String field 25, 57
accounts, defined 185
Active AMPS field 58, 133
active rule set 170
Active Rule Set command 31
Active Rule Set Information dialog box 170
Add Workload Classification dialog box 139
Add Workload dialog box 59, 70, 77, 96
allocation group
defined 185
Priority Scheduler settings field 41
Analysis menu commands
Convert PDSets to Workloads 31
Existing Workload Analysis 31
New Workload Recommendations 31
Analyze Workload window 65, 74
Authentication Mechanism field 24
Authentication Parameter field 24
Auto-Generate Workloads dialog box 71
Avg Est Processing Time field 57
C
Candidate Workload Report 56, 131, 171
candidate workload summary 170
Candidate Workloads tree 32
category of work 91
classification criteria
application example 155
by excluded objects example 156
defined 150
defining #1 for WDs 151
defining #2-6 for WDs 152
displaying 154
QueryBand example 157
Classify by excluded objects
merged workloads 144
split workloads 142
Classify By... dialog box 140
client address formats 152
CLIv2, defined 185
columns, defined 185
configuration
application options 23
configuring
application options 29
Connect command 31
Connect to Teradata Database
dialog box options
advanced 24
basic 24
ways to connect 23
Convert PDSets to Workloads command 31
copying DBQL data 22
CPU
per Query field (Seconds) 57, 133
Skew (Percent) field 133
Skew field 58
To Disk Ratio field 58, 133
creating local exception directives 161
D
Data Collection Interval dialog box 38
data manipulation language, defined 186
database
connecting 23
permission requirements 19
DBC, defined 185
DBCAREA, defined 185
DBQL
access external databases 19
defined 186
detail logging 22
large volumes of data 22
Step Table, enabling 22
summary logging 22
DBQLSQLTbl 167
DBQM, defined 186
DDL, defined 186
deeper drill-down analysis and refinement 96
process 98
general example 102
example with querybands 109
Default Database field 25
Define DBQL Inputs dialog box 52, 128, 170
Define Periods (Operating Environments)
dialog box 25, 36
Define System Periods
command 32
189
Index
menu item 25
defining
exception actions 166
exception criteria 163
Disconnect command 31
disconnecting from the Teradata Database 25
Disk I/O Per Query field 58, 133
distinct value counts in a workload 29
DML See data manipulation language
E
enforcement priorities, defining 91
dialog box 77
histogram 78
option 75
evaluation order, and candidate workloads 172
exception actions
defined 159
defining 166
exception criteria
defined 159
defining 163
deleting 163
exception directives 169
defined 159
global 160
local 160
setting precedence 168
exception handling guidelines 169
Existing Priority Scheduler Weights dialog box 42
Existing PSA Setting
dialog box 41
tab 40
existing workload analysis 128
Existing Workload Analysis command 31
Exit command 31
exiting Teradata WA 23
External DBQL log option 19
F
File menu commands
Connect 31
Disconnect 31
Exit 31
G
global exception directives 160
glossary 185
goals for workload analysis 49
190
H
handling concurrent multiple exception directives 169
help
menu commands
About SQL Assistant command 33
About Teradata Workload Analyzer 32
Help Contents 32
online help 33
I
I/O Skew field 58, 133
ID, defined 186
initial workload periods
adding 25
defining 25
J
JDBC, defined 186
L
local exception directives 160
logging DBQL
detail or summary 22
enabling
detail 22
Step Table 22
summary 22
login 23
M
macros, defined 186
Merge Workloads dialog box 137
merged workloads 144
Migrated TASM Settings tab 43
Milestone field 41
Milestone Value field 41
N
Navigation Help
command 31
using 33
New Workload Recommendations command 31
O
online help 33
Options
command 32
configuring application options 29
define Teradata WA options 30
Index
P
parameters, defined 186
Password field 24
Percent of Total I/O field 57
Perform Analysis button, and viewing graphs 68
PG Name field 41
PG Status field 41
planning for workload analysis 49
Post to Queue Table
exception action relationships 169
for exception events 167
precedence, setting for exception directives 168
preview classification 71
Priority Scheduler migration
adding initial workload periods 25
Priority Scheduler settings
converting to workloads 43
viewing 41
procedures, defined 186
product introduction 15
product version numbers 4
PSA to DWM Conversion - CPU Distribution dialog box 44
Q
Query Count field 57
query management, defined 187
QueryBand, classification criteria example 157
R
recommendations, generating for workloads 51
requests, defined 187
requirements
database permissions 19
software 20
Teradata CLIv2 20
Teradata Database 20
resource partitions, defined 187
Response Time field 58, 133
Result Row Count field 58, 133
RP Name field 41
rule set
active 170
workload 17
rules
defined 187
workload management, creating 21
defining 88, 133
not met 127
splitting workloads when not met 138
Session character set 24
sessions, defined 187
Set Enforcement Priority dialog box 92
Show distinct count 30
shutdown 23
SLG Met Details field 132
SLG Recommendations window 46, 89, 133
SLG Tier Hints Report 181
software requirements 20
Split Workloads dialog box 138
Spool Usage field 58, 133
starting Teradata WA 23
statements, defined 187
Status Bar command 31
Subject Area Resource Division 91
System (DBS) Name field 24
T
tables, defined 187
TASM
enabling 21
how it works with Teradata WA 15
TASM PreMigration Tool 181
TDWM database, connection 23
TDWMExceptionLog 167
Teradata CLIv2 requirements 20
Teradata Database
connecting 23
disconnecting 25
Regulator component 17
requirements for running 20
Teradata Dynamic Workload Manager command 32
Teradata WA
exiting 23
introduction to 15
starting 23
Toolbar command 31
Tools menu
Define System Periods option 25, 32
Options command 32
Teradata Dynamic Workload Manager command 32
troubleshooting. See help 33
U
S
user interface, navigating 30
User Name field 24
Save Rule Set dialog box 95
Select PDSet(s) dialog box 36
Select Rule Set dialog box 27
service level goals
V
version numbers 4
191
Index
View menu commands
Active Rule Set 31
Navigation Help 31
Status Bar 31
Toolbar 31
viewing graphs 68
Viewpoint 17
Viewpoint Workload Designer 16
views, defined 187
W
WDs
defining classification criteria #1 151
defining classification criteria #2-6 152
displaying classification criteria 154
wild card filters and creating workloads 61
workload analysis, overview 17
Workload Health 17
Workload Monitor 17
Workload Prefix field 30
Workload-Allocation Group Mapping dialog box 93, 94
workloads
attributes, viewing 147
creating 94
management rules, creating 21
mapping to allocation groups 90
maximum number supported 56
periods, defining 25
planning analysis of 49
recommendations, generating 51
rule sets, creating 17
viewing or modifying attributes 147
Z
Zoom In dialog box 78
192

Teradata Workload Analyzer

Transcription

Similar documents

sonia cordero cardenas san andres university – la paz •jaime rojas

Characterizing On

AcroSoft Work Management

OmniCube CN-3000

Exchange Report

Freedom to Explore - Teradata Magazine Online

from polimi.it - Dipartimento di Elettronica ed informazione

Measuring and Managing SLP Workload and Caseload (OSSPEAC