TERADATA PERFORMANCE: WHY

DBQL MATTERS THE MOST

Barbara Christjohn
Wendy Hwang

April 2013

Barbara Christjohn
Principle Consultant
Principal Consultant with Teradata's
Performance and Workload Management
Center of Expertise.
Over 20 years of Teradata experience
Teradata 12 Certified Master
Has worked on many customer
implementations specializing in database
administration, physical database design,
data integration, performance tuning,
workload management, and capacity
management.

Teradata Confidential

Wendy Hwang
Sr. Consultant
Senior PS Consultant with Teradata's
Performance and Workload Management
Center of Expertise
13 years of Teradata experience
Worked for 7 years as an Architect for a
large Telecommunication companys Billing
System and then 6 years as a Teradata
Consultant focused on Workload
Management, Data Collection, Capacity
Planning and Projection and
Performance tuning for a number of
customers.

Teradata Confidential

Agenda
DBQL Overview

Application Performance Decisions

Prioritizing tuning efforts

Analyzing object usage
Quantifying performance improvements

Workload Management Decisions

DBQL Table Contents

Best practices on logging and retention
Understanding the Performance Indicators

Validating effects of workload changes

Reviewing throttle related Information
Characterizing workloads

Teradata Confidential

DBQL OVERVIEW

DBQL Basics The Tables

DBQLSqlTbl

Holds full SQL text

DBQLogTbl

For individual
queries:
query origination
start, stop and other timings,
error codes, TASM data,
SQL (truncated)
CPU AND I/O values

DBQLSummaryTbl

Populated by Summary or
Threshold Logging:
short, known work
username, acct, aggregated
response time, CPU, I/O,
and
query counts

DBQLObjTbl

Tracks usage of database objects

(tables, columns, indexes,
database,etc)

DBQLStepTbl

query step timings, row

counts, CPU and I/O, step actions,
etc

DBQLExplainTbl

Holds full EXPLAIN text

DBQLXMLTBL

Holds optimizer query plans as XML

documents
Teradata Confidential

TD13 Notable Enhancements

For Rules You Set up that may Overlap, DBQL will choose which rule
to apply based on a "best Fit Rule" hierarchy.
DBQL rules are searched for and applies based on the following order:
A
A
A
A
A

rule
rule
rule
rule
rule

based on an application name

for a specific user and a specific account
for a specific user and any account
for all users and a specific account
for all users and any account

The SHOW QUERY LOGGING command displays the DBQL rule the
system would apply for a user or user-account pair.
Example: Show Query Logging on systemfe;

The BEGIN QUERY LOGGING statement has a new "WITH NONE"

option to disallow logging for a particular user, or group. While this
is an option, it is not recommended. Best Practice is to log ALL
usage. Determining how to log is based on Workload
Characteristics and is outlined below.
The END QUERY LOGGING statement has a new option that deletes
all the rules in the rule cache (ON ALL RULES)
If a user changes his active session through a SET SESSION
ACCOUNT command, DBQL enables rules associated with that
account when the user issues a query from the new account.
7

Teradata Confidential

TD 13.10 Notable Enhancements

The DBQL XMLPLAN option has been enhanced to log additional
Information
Actual AMP resource usage and row counts
User and session information

The XML schema has been enhanced

Clear distinction between the user and its execution plan
Better descriptions of relations as it relates to their use a s source or target
within a step
Replace StepAttributes with explicit custom step information for various step
types

Database Query Logging enhancements include

Allowing the LIMIT THRESHOLD in combination with SQL, STEPINFO and

Objects logging options
TypeOfUse column in the Object Table is now populated
New REPLACE Query Logging Command

Data Dictionary Archive

Now archives the DBQLRuleTbl and DBQLRuleCountTbl

Teradata Confidential

TD14 Notable Enhancements

New Logging Option STATSUSAGE

Stored in XML table like XMLPLAN logging option

Published schema that describes the structure and content of the
logged XML documents
The data can be extracted using XML Services features or any offthe-shelf XML parser.
The content logged by STATSUSAGE in release 14.0 is the same
data you would get from existing feature INSERT EXPLAIN CHECK
STATISTICS
The primary motivation for implementing STATSUSAGE is for
AutoStats in a future release but users are free to use it for their
own custom purposes

Teradata Confidential

Logging Best Practice TD13 and Above

All Usage should be logged 24X7
Set One System Level Logging Statement that logs all usage
at the detail level with SQL and Objects
BEGIN QUERY LOGGING WITH SQL, OBJECTS LIMIT SQLTEXT=0 ON ALL;

Next determine the best way to log each

user/account/Application that should not be logged as the
default above, based on usage analysis.
For any individual users, accounts, or applications that would be
better logged Summarized
TD13.10 - BEGIN QUERY LOGGING WITH OBJECTS,SQL LIMIT
SQLTEXT=0 AND THRESHOLD=100 CPUTIME ON All ACCOUNT =
acctnm;
TD13 - BEGIN QUERY LOGGING LIMIT THRESHOLD=100 CPUTIME
AND SQLTEXT=10000 ALL ACCOUNT = acctname;
You can also use
ON APPLNAME = 'applicationname' or
ON <username>
or a user/account combination

10

Teradata Confidential

DBQL - Retention
Move Data from DBC to History Tables Nightly

Maintenance processes are available for each release of Teradata

out on the Developers Exchange under Downloads
Migration Scripts to Move Existing Data to your new Release
History Tables is also available on the Developers Exchange
Recommended
DBC

11

History Database

DBQLogTbl

Current Day

13 Months

DBQLSummaryTbl

Current Day

13 Months

DBQLObjTbl

Current Day

3 Months

DBQLSqlTbl

Current Day

3 Months

DBQLStepTbl

As Needed

As Needed

DBQLExplainTbl

As Needed

As Needed

DBQLXMLTbl

As Needed

As Needed

Teradata Confidential

Recommendations for Historic DBQL Data

If space is a concern consider changing retention not the logging strategy!
Recommendation for DDL on Historical DBQL
Create new date column populated from Starttime on all tables
Put PPI on new date column to provide better performing analysis
Regular Statistics collections
Join between DBQL tables on QueryId
End logging on at least one user to dump the cache to ensure all
DBQL history is captured
Begin logging on the user again
Keep history tables similar to DBC DBQL tables for other tools like
Teradata Workload Analyzer (TWA)
Create views with the same name as the DBC table for other tools
like TWA

12

Teradata Confidential

Accountstrings - Note on Formatting

Logging is done by the contents of the AccountString
Should contain the Performance Group, Application/Workload
Indicator and &S&D&H ASE variables
&S Session Number
&D Date
&H Hour
Example $M1$MSIR&S&D&H
Where MSI = Application Identifier
Where R = Workload Identifier ( Reporting, Batch, Tactical, Online)
Use a format like $M0+ or $M00 for default partition Priority
Groups
DBC AccountString cannot change limit use of the DBC UserId
For a new customer who only and always plans to use TASM, and
doesn't have "old PG names" or the AccountString does not conform
to the above standard then it can be:
XXXXYYYY&S&D&H
Where X = Any Character Y = Workload Identifier
13

Teradata Confidential

Performance Indicators in DBQL

Use the information available to determine Which
Queries are not optimized
Identify Why Queries may not be optimized
The Performance Indicators
Product Joins - Too Much CPU compared to IOs (PJI)
Large Scans - Too Much IO with Little CPU (UII)
CPU or IO Skew (CPUSkw or IOSkw)
Impact CPU (a measure of the Impact of Skewing)
High CPU or IO
Significant Response Time

14

Teradata Confidential

Using DBQL to Find Product Joins

Product Join Indicator (PJI)
A Value of 1 shows NO Indication of a Product Join 3 and
Higher warrants investigation
Case when TotalIOCount = 0 then 0
else (AMPCPUTime * 1000)/TotalIOCount End

Getting False Product Join Indicators

These operations are done in Memory - They Get One IO and
then use lots of CPU
Large Aggregations
Example: Select count(*) from LgTbl WHERE Xyz_Dt between date-365 and date-1;
Numerous substrings, case statements, indexing into character strings
Numerous Duplicate Row Checks

The more Rows in a Data Block that CPU has to work on, the
higher the PJI
Sparse Join Index, PPI, and a High volume of Multi-Value Compression

The PJI is also known as the Larry Higa Ratio (LHR)

15

Teradata Confidential

Using DBQL to Identify Large Table Scans

UnNecessary IO Indicator (UII) Inefficient use of IO
per CPU
A Value of 1 shows NO Indication of a Large Scan 3 and
Higher warrants investigation
Case when AMPCPUTime = 0 then 0
else TotalIOCount/(AMPCPUTime * 1000) End

Getting False Large Scan Indicators

Some Processes, like ETL type work, will often have a High UII
In most cases, there is nothing that can be tuned
High volume of or large redistributions could also cause a High
UII

This is the Inverse of the PJI Calculation

The UII is also known as the Inverse of the Larry
Higa Ratio or RHL
When this number is high, it is an indication that the
Query could be optimized by using an Index
16

Teradata Confidential

Using DBQL to Find Skewing

Using SQL to Query DBQL Detail to Calculate Skew
CPU Skew Number - A Value of 1 is NOT Skewed
Case when (AMPCPUTime / (hashamp()+1) =0 then 0
else MaxAmpCPUTime/(AMPCPUTime / (hashamp()+1) End

IO Skew Number - A Value of 1 is NOT Skewed

Case when (TotalIOCount / (hashamp()+1) =0 then 0
else MaxAmpIO/(TotalIOCount / (hashamp()+1) End

Getting the Number of Amps without Hardcoding

Use (hashamp()+1) as AMPQTY
We use 1.25 as the threshold, but often find that there may be
nothing to tune unless its higher than 2 or 3.
Example: Skew Number Calculates to 2
In Theory, the skewing could cause the query to take 100%
longer than if there was no skew.
17

Teradata Confidential

Using DBQL to Determine the Impact of Skewing

High impact CPU
Use to compare skewed queries Helps see the effect of
skewing
MaxAmpCPUTime * (Hashamp()+1)

Compare to total CPU

Which query causes more trouble on the system?

Query 1

18

Query 2

Total CPU = 3,000

Total CPU = 700

CPU Skew = 1.2

CPU Skew = 8

I/O Skew = 1.2

I/O Skew = 8

PJI = 1

PJI = 1

Impact CPU = 3,200

Impact CPU = 8,500

Teradata Confidential

APPLICATION PERFORMANCE
DECISIONS

Measure Query Performance

EXEC SuspQuerysDtRng_Rpt (date-30, date, 100); (Macro is in Bonus Section)

UserName

AcctString

MickyM
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
HarleyD
PenelopeP
MickyM
PenelopeP
MickyM
PenelopeP
MickyM
MickyM
PenelopeP
BufordG

$L2$ADHR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$SASR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$ADHR&S&D&H
$L2$SASR&S&D&H

20

Statement
Type
Create Table
Select
Select
Select
Select
Select
Select
Select
Select
Select
Select
Select
Select
Select
Select
Select
Update
Create Table
Create Table
Select
Create Table
Create Table
Update
Select
Select

AppID
QUERYMAN
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
SAS
QUERYMAN
QUERYMAN
QUERYMAN
QUERYMAN
QUERYMAN
QUERYMAN
QUERYMAN
QUERYMAN
SAS

QryRespTime
1 07:54:10.03
0 03:01:14.05
0 01:46:39.58
0 07:44:17.46
0 06:07:41.45
0 01:18:16.85
0 01:19:30.83
0 02:37:42.37
0 01:02:31.29
0 01:05:19.78
0 04:05:58.31
0 00:58:07.97
0 01:01:12.43
0 5:59:53.62
0 00:55:45.25
0 00:52:39.36
0 04:20:11.14
0 16:41:53.90
1 01:21:05.46
0 15:20:35.60
0 04:41:16.58
0 15:30:39.55
0 03:35:23.65
0 22:06:17.35
0 00:40:58.68

NumResult
Rows

SumCPU

0
134,365,789
213,654,368
110,834,638
456,326,879
568,432,856
238,012,865
1,357,680,113
567,335,689
976,543,953
435,478,973
986,543,297
1,223,222,545
1,569,452,435
1,485,905,432
1,865,796,435
0
0
0
884
0
0
0
2,183
4,633

Teradata Confidential

SumIO

10,598
85,780,444
5,661
4,234,997
5,774
4,183,694
5,648
4,195,805
5,696
4,187,886
5,712
4,190,542
5,680
4,231,295
5,577
4,198,609
5,515
4,178,118
5,802
4,192,639
5,742
4,205,678
5,543
4,240,820
5,467
4,233,188
5,489
4,203,847
5,365
4,193,370
5,374
4,183,438
21,259 290,033,576
680,412 2,477,979,103
10,881 137,939,071
568,285
1,934,854
10,097 137,059,513
487,701 192,287,838
8,463
38,034,709
3,619
3,753,325
3,462
3,755,376

CPUSKW
325.36
168.11
164.09
166.41
164.67
162.56
163.42
166.35
168.11
159.34
160.49
165.04
166.76
165.58
165.95
165.01
38.16
26.51
63.94
88.43
56.11
24.12
111.16
127.26
132.96

IOSKW

PJI

UII

353.16
0.12
8.09
22.25
1.34
0.75
22.85
1.38
0.72
22.48
1.35
0.74
22.53
1.36
0.74
22.37
1.36
0.73
22.25
1.34
0.75
22.44
1.33
0.75
22.58
1.32
0.76
22.44
1.38
0.72
22.75
1.37
0.73
23.32
1.31
0.77
24.21
1.29
0.77
23.18
1.31
0.77
22.59
1.28
0.78
23.04
1.28
0.78
6.99
0.07 13.64
1.02
0.27
3.64
187.41
0.08 12.68
1.02 293.71
0.00
186.82
0.07 13.57
1.02
2.54
0.39
8.57
0.54
1.87
10.75
0.96
1.04
10.61
0.92
1.08

ImpactCPU
3,448,095
951,681
947,471
939,910
937,928
928,586
928,158
927,691
927,212
924,546
921,498
914,843
911,652
908,885
890,302
886,695
811,227
700,068
695,675
681,495
566,603
495,701
484,655
460,536
460,341

CPU Consumption By Work Group

1 Day Node Equivalent Calculation*: ((86400*#CPUs Per Node) 20%
EXEC TrendAnalysisDtRng_Rpt (date-7, date); (Macro is in Bonus Section)

8847360

15 Nodes

Sum of SumCPU

8294400
7741440
7188480

12 Nodes

6635520
WorkGroup

6082560

SYSX
RSKR
MSIR
MKTR
FINA
EDWL
DBAS
COGR
ADHR

5529600

9 Nodes

4976640
4423680
3870720

6 Nodes

3317760
2764800
2211840

3 Nodes

1658880
1105920

1 Node

552960
0
8/9/2010

8/10/2010

8/11/2010

8/12/2010

8/13/2010

8/14/2010

LogDate

21

*Node Equivalency as measured by DBQL

Teradata Confidential

8/15/2010

8/16/2010

CPU Consumption By Work Group by Hour

1 Hour Node Equivalent Calculation*: (((86400*#CPUs Per Node) 20%)/24
Sum of SumCPU

Note: Hours can go over

actual system capacity
because a Requests CPU
consumption is logged in the
hour it started

SAS
SQLA
BTEQ

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

737280
714240
691200
668160
645120
622080
599040
576000
552960
529920
506880
483840
460800
437760
414720
391680
368640
15 Nodes345600
322560
299520
12 Nodes276480
253440
230400
9 Nodes207360
184320
161280
6 Nodes138240
115200
92160
3 Nodes 69120
46080
23040
0

8/9/2010

8/10/2010
LogDate HR

22

Teradata Confidential

AppID
TPTUPD
TPTLOAD
TPTEXP
TDCLIENT
SAS
QUERYMAN
NVTERA
MULTLOAD
MSQRY32
MSACCESS
FASTLOAD
FASTEXP
EXCEL
DATABASEBROWSER
COGTR
BTEQ
BMT
BIBUSTKSERVERMAIN
ARCMAIN

CPU Consumption by Suspect Usage By Day By AppId

3870720

AppID

Sum of TotPJSkwLgScanCPU

3317760

5 Nodes

2764800

4 Nodes

2211840

3 Nodes

1658880

2 Nodes

1105920

SAS

SAS

SQLA

SQLA
552960

LogDate

23

Teradata Confidential

8/22/2010

8/21/2010

8/20/2010

8/19/2010

8/18/2010

8/17/2010

8/15/2010

8/14/2010

8/13/2010

8/12/2010

8/11/2010

8/10/2010

8/8/2010

8/7/2010

8/16/2010

BTEQ

BTEQ

8/9/2010

1 Node

TPTUPD
TPTLOAD
TPTEXP
TDWM
TDCLIENT
SQLA
SAS
QUERYMAN
PERL
NVTERA
MULTLOAD
MSQRY32
MSACCESS
FASTLOAD
FASTEXP
EXCEL
DATABASEBROWSER
COGTR
BTEQ
BMTMDPROVIDERMAIN
BMT
BIBUSTKSERVERMAIN
ARCMAIN
ADHOC

Skew, PJ Characteristics, Large Scan by AppId

TPTUPD
TPTLOAD
TPTEXP
TDWM
TDCLIENT
SQLA
SAS
QUERYMAN
PERL
NVTERA
MULTLOAD
MSQRY32
MSACCESS
FASTLOAD
FASTEXP
EXCEL
DATABASEBROWSER
COGTR
BTEQ
BMTMDPROVIDERMAIN
BMT
BIBUSTKSERVERMAIN
ARCMAIN
ADHOC

1105920

552960

8/22/2010

8/21/2010

8/20/2010

8/19/2010

8/18/2010

8/17/2010

8/16/2010

8/15/2010

8/14/2010

8/13/2010

8/12/2010

8/11/2010

8/9/2010

8/10/2010

8/7/2010

Serious Product Join

Problems are rare
Large Volume of
Opportunity is SAS and
SQLA Skewing and Large
Scans

AppID

Sum of SkwdQryCPU

8/8/2010

In This Example

1658880

LogDate

AppID

2211840

1658880

1105920

552960

LogDate

Teradata Confidential

8/22/2010

8/21/2010

8/20/2010

8/19/2010

8/18/2010

8/17/2010

8/16/2010

8/15/2010

8/14/2010

8/13/2010

8/12/2010

8/11/2010

LogDate

24

AppID

Sum of LgScanCPU

8/10/2010

8/22/2010

8/21/2010

8/20/2010

8/19/2010

8/18/2010

8/17/2010

8/16/2010

8/15/2010

8/14/2010

8/13/2010

8/12/2010

8/11/2010

8/9/2010

8/10/2010

8/8/2010

8/7/2010

2764800

8/9/2010

552960

TPTUPD
TPTLOAD
TPTEXP
TDWM
TDCLIENT
SQLA
SAS
QUERYMAN
PERL
NVTERA
MULTLOAD
MSQRY32
MSACCESS
FASTLOAD
FASTEXP
EXCEL
DATABASEBROWSER
COGTR
BTEQ
BMTMDPROVIDERMAIN
BMT
BIBUSTKSERVERMAIN
ARCMAIN
ADHOC

8/8/2010

Sum of PJQryCPU

8/7/2010

1105920

TPTUPD
TPTLOAD
TPTEXP
TDWM
TDCLIENT
SQLA
SAS
QUERYMAN
PERL
NVTERA
MULTLOAD
MSQRY32
MSACCESS
FASTLOAD
FASTEXP
EXCEL
DATABASEBROWSER
COGTR
BTEQ
BMTMDPROVIDERMAIN
BMT
BIBUSTKSERVERMAIN
ARCMAIN
ADHOC

No More Spool and No More Room in Database

Errors are often caused by skewing
The Errorcode and ErrorText columns in DBQL can also provide
Performance Information
DBQL and Acctg does not accurately reflect CPU and IO numbers for
Errored Requests so The Skew volume in the previous slide does not
accurately represent these queries.
Also, the Chart below does not accurately reflect all the CPU thats
wasted by these errorred requests, but its a start

300000

Sum of SumCPU

250000

200000

ErrorAbortType
NoMoreSpool
NoMoreRoominDB

150000

100000

50000

25

BTEQ

Teradata Confidential

QUERYMAN

AppID

SAS

CPU Consumption of User Aborted Queries

Using the Errorcode and Errortext columns can can also provide You
with insight into Users that are running SQL that they later end up
aborting
This can often happen when adhoc users run SQL that they didnt
EXPLAIN first
In this example, since most of this is happening in SQL Assistant, its
very easy for End Users to do an explain

ErrorAbortType UserAborted

1105920

Sum of SumCPU

AppID

1 Node

SQLA
SAS
QUERYMAN
BTEQ

552960

LogDate

26

Teradata Confidential

8/23/2010

8/22/2010

8/21/2010

8/20/2010

8/19/2010

8/18/2010

8/17/2010

8/16/2010

8/15/2010

8/14/2010

8/13/2010

8/12/2010

8/11/2010

8/9/2010

8/10/2010

8/8/2010

8/7/2010

8/6/2010

8/5/2010

8/4/2010

8/3/2010

8/2/2010

8/1/2010

7/31/2010

7/30/2010

7/29/2010

7/28/2010

7/27/2010

7/26/2010

7/25/2010

DBQLObjTbl -Object Types Logged in TD 13

Most Commonly Used

Col = Column
DB = Database
Hix = Hash Index
Idx = Index
JIx = Join Index
Mac = Macro
Tab = Table
Tmp = Temporary
Viw = View
Vol = Volatile

27

The Others
Agg = User defined aggregate function
AgS = User defined aggregate STAT function
Aut = Security Authorization
GLp = GLOP Set
Jrl = Journal
Not = No Type
SP = Stored Procedure
Sta = User defined STAT function
TbF = Table function
Trg = Trigger
UDF = User defined function
UDM = User defined method
UDT = User defined type
XSP = External Stored Procedure

Teradata Confidential

Tables with No Statistics

7000000

700000

6000000

600000

5000000

500000

4000000

400000

3000000

300000

2000000

200000

1000000

100000

Teradata Confidential
DatabaseName

S_ZZTEMP

S_UTL_ETL

This is can be charted by Tablename.

Tablenames removed to protect customer information

S_UTL_USR

S_SPRJ

S_TU_ADE

S_SHRT

S_RAD

S_PCM

S_PULSE

S_MYVIEW

S_MRCHTS

S_MRKTNG

S_GATE

S_LAWAUDIT

S_FIN_PERF

S_DCI

S_DPL

S_CSD

S_CORP_RISK

28

S_CLB

S_CCP

S_CIMS

S_BTGRP

The Chart Below joins Data Dictionary Information on Statistics Collection to

DBQL Object and Log Data, comparing CPU Consumption of Requests Used
by Tables with No statistics to the ImpactCPU.
The Larger the Disparity between CPU and ImpactCPU, the higher priority
resolving the missing statistics could be.
There could be other causes for Skew, but checking missing statistics is a
good starting place

S_BAS

Data
Sum of SumCPU
Sum of SumImpactCPU
Sum of FreqofUse

Check For Statistics Over-Collection

In This example, the Total CPU Consumption of all Multi-column statistics
collection for tables in the production database is approximately 4.7 million
CPU Seconds over a month.
Its worth checking to see if these statistics are useful

This is can be charted by Tablename.

Tablenames removed to protect customer information

29

StatementType = Collect Statistics

Teradata Confidential
ObjectType = TAB

Two Useful Tools for Determining

What Missing Statistics to Collect
DIAGNOSTIC HELPSTATS ON FOR SESSION;
Submit the diagnostic request one time from within your session
At the end of all subsequent EXPLAINs are the optimizers recommendations for
statistics collection
Guidelines for Using the Recommendation Output

Single column and Index recommendations should be collected,

but multi-column recommendations (which are more expensive
and can be inaccurate) need to be carefully looked at, and tested
for effectiveness. If the query plan does not gain from the
collected statistics drop them to reduce system overhead!
This diagnostic does not recommend Sample Stats. If a column is highly unique
consider sample.
This is an unsupported diagnostic, so incorrect or unnecessary recommendations are
not grounds for contacting Support

Statistics Wizard can be used to Determine Missing Statistics

The Wizards Work Best When Using a Workload of less than than 30 Queries

30

Teradata Confidential

Skew Tables
TableName

Prod1

TblABC

1,968,640.00

99,342,336.00

2,271,820.46

851,932,672.00

43.73

Prod1

TblFGH

32,256.00

263,145,472.00

754,910.55

283,091,456.00

348.58

Prod1

TblMNO

1,024.00

14,932,992.00

222,640.81

83,490,304.00

67.07

Prod1

TblSTU

65,024.00

5,588,992.00

208,920.58

78,345,216.00

26.75

MaxCurrPerm

AvgCurrPerm

TotCurrPerm

1800000

2000

1600000

1800
1600

1400000

1400
1200000
1200
1000000
1000
800000
800
600000
600
400000

400

200000

200

TblABC

TblMNO

TblPQR
TableName StmtType

Teradata Confidential

TblSTU

Write

LoadUtil

Collect Statistics

Write

LoadUtil

Collect Statistics

Write

LoadUtil

Collect Statistics

Write

Collect Statistics

Find Skewed Data

Tables Using
DBC.Tablesize

Then Use DBQL to

Determine How Often
the Tables are Used
along with CPU and
ImpactCPU

The Larger the

Disparity, the higher
priority resolving the
the data skew could be.

There could be other

causes for the Query
Skew shown in the
chart
31

MinCurrPerm

Skew
Factor

DataBaseName

Data
Sum of SumCPU
Sum of SumImpactCPU
Sum of FreqofUse

Secondary Index Use

Use DBQL Object Data 90 Days is Usually a good
representation
If Secondary Indexes are Not Used, Remove them
This will Speed Up the Batch Processes by not having to
maintain Secondary Indexes during the Loads and maybe not
having to collect statistics
Get Table Size Information from DBC.Tablesize The larger
the table, the more impact to the load

Similar analysis can be done on Join Indexes

32

Teradata Confidential

Drop Unused Tables

Use DBQL Object Data joined to DBC.Tablesize to Determine When Tables
have not been used and their size 90 days is usually a good representation
When your free cylinders gets below 10% you know youll be hitting a
capacity issue - once it gets <5% youll likely be cylinder packing and have
performance degradation. Only empty cylinders can be used for spool.

Num Tbls

Space Consumed

33

Teradata Confidential

Avoid Select * From When just wanting

to see what the data looks like

From Doing this Analysis

at the AccountString
level, it allowed us to
easily identify the
Development group
selecting a lot of rows
By Looking at the Actual
Queries Logged, weve
identified that they are
Numerous Large Select *
From Statements
Calling a couple of Users,
produced the answer we
just want to see what the
data looks like.

3500000000

Sum of SumRowsRtnd

3000000000
AcctString
DBC
$R__MSP&S&D&H
$R__ETL&S&D&H
$L__VUE&S&D&H
$L__TDM&S&D&H
$L__SYS&S&D&H
$L__MSE&S&D&H
$L__ETL&S&D&H
$L__DEV&S&D&H
$H__ETL&S&D&H
$H__CRM&S&D&H
$H__ARC&S&D&H
$H__ADM&S&D&H

2500000000

2000000000

1500000000

1000000000

500000000

0
7/26/2010

7/27/2010

7/28/2010

7/29/2010

7/30/2010

7/31/2010

8/1/2010

8/2/2010

LogDate

Rows
Spool
Time Ran
Total CPU
total
34 I/O

Without Sample
With Sample Sel Top 2000 *
2,579,781,818.00
2,000.00
2,000.00
253,013,456,896.00
513,024.00
228,864.00
03:26.4 0:10.01
0:22.02
1,732.04
9.63
0.35
4,672,244.00
23,762.00
33 Confidential
Teradata

Analysis shows using Top

is even more efficient than
Sample. Note the CPU and
IO differences.

MultiLoad Analysis
Use the UtilityRowCount Values in the DBQLogTbl to validate that a
Utility Load is appropriate
Mload Analysis
Week 08/09
& 08/16
While Every System is Different,
reducing
unnecessary
utility use can
free up AWTs,
put less burden on MaxLoadTasks and improve response
1,800
times

1,600

1,400

20 to 25% of
MLOADs load
less than
1,000 rows

# of Mloads

1,200
Over 100,000
Between 50,001 to 100,000
Between 10,001 to 50,000
Between 5,001 to 10,000
Between 1,001 to 5,000
Between 0 to 1,000

1,000

800

600

400

200

0
0

10 11 12 13 14 15 16 17 18 19 20 21 22 23
Hour

35

Teradata Confidential

Measure the Affects of Tuning Efforts

Use DBQL Data to Compare Performance Measurements
Example Shows the Impact of Tuning a Significantly Skewed
Query
Current Request

Request with Tuning

UserName

BI_ETL_Usr

Tuner_id1

Frequency

Every Day

StartTimeStamp for
1 occurrence

2009-03-11 11:59:04.25

2009-04-08 10:47:28.42

Duration

4 Hours 41 Minutes

1 Minute 7 Seconds
(PSF Priority is 4X less than production id)

CPU Consumption

13,351 CPU Seconds

293 CPU Seconds

IO Count

17,461,158

1,117,554

CPU Skew

46.44

1.05

ImpactCPU

288,842

308

36

Teradata Confidential

Quantify Tuning Efforts

Chart Shows that tuning
significantly reduced total
CPU consumption
BUT Doesnt rule out that
maybe there just wasnt much
running the last 3 days
25

500

400
20
300

15
200
Data
Average of Average(AMPCPUTime)
Average of AvgElapsedTime
100
10

Further Review Shows that Average CPU

Consumption went from 6 to under one CPU
-100
Seconds
And Average Response time not only
-200
improved but became more consistent due to
now qualifying for a High Priority TASM
Teradata Confidential
setting reserved for subsecond CPU queries
0

01
23
45
67
9
10
11
12
14
15
16
17
18
19
20
21
22
230
12
34
56
79
10
11
12
13
14
15
16
17
18
19
20
21
22
230
12
34
56
79
10
11
12
13
14
15
16
17
18
19
20
21
22
230
12
34
56
79
10
11
13
14
15
16
17
18
19
20
21
22
230
12
34
56
79
10
11
12
13
14
15
16
17
18
19
20
21
22
230
12
34
56
79
10
11
12
13
14
15
16
17
18
19
20
21
22
230
12
34
56
79
10
11
12
13
14
15
16
17
18
19
20
21
22
23

0
1/24/2010

37

1/25/2010

1/26/2010

1/27/2010
LogDate Hour

1/28/2010

1/29/2010

1/30/2010

Using DBQL Step Data

Each step contains start and finish times, resources used,
and all the Performance Indicators can be calculated for each
step
Look at differences between estimated row count and actual for
each step
Can show blocking (not what was blocked)
All amp operation taking long time even though not using much
resources may indicate AWT shortage
Query taking long in aggregation step may indicate aggregate join
index will help

Use to identify plan changes when moving to New Releases

or other System Changes
Can be done by # of steps or type of steps

Should always be logged in conjunction with DBQLExplainTBL

38

Teradata Confidential

Train and Facilitate Users to Measure their Own

Query Performance
Replace macro MyQrysDt (dt date)
as ( SELECT a.UserName, a.LogDate, SessionId, a.ProcId, a.QueryId, a.AcctString, ExpandAcctString , DefaultDatabase, SpoolUsage,
StartTime, TotalRespTime, TDWMDelayTime, DelayTime, NumOfActiveAmps, NumResultRows, SumCPU, SumIO, CpuSkw , IOSkw, PJI,
UII , ImpactCPU, SqlRowNo,
Case When s.sqltextinfo is not null or s.sqltextinfo = ' ' Then substr(s.SQLTextInfo,1,15000) Else a.querytext End as QryText
FROM ( SELECT
a.UserName ,a.logdate ,a.sessionid ,a.ProcId ,a.QueryId , a.acctstring ,a.expandacctstring , a.defaultdatabase
,a.SpoolUsage, a.Starttime,
((firstresptime-Starttime) day(4) to second) as TotalRespTime,a.DelayTime as TDWMDelayTime , ((firststeptime-Starttime) day(4) to
second) as DelayTime,
NumofActiveAmps,NumResultRows, a.AMPCPUTime as SumCPU , a.TotalIOCount as SumIO,
Case when (AMPCPUTime / (hashamp()+1) ) =0 then 0 else MaxAmpCPUTimeNorm/(AMPCPUTimeNorm / (hashamp()+1) ) End
(dec(6,2)) as CpuSkw,
Case when (TotalIOCount / (hashamp()+1) ) =0 then 0 else MaxAMPIO/(TotalIOCount / (hashamp()+1) ) End (dec(6,2)) as IOSkw,
Case when a.TotalIOCount = 0 then 0 else (a.AMPCPUTime *1000)/a.TotalIOCount end (dec(6,2)) as PJI,
Case when a.AMPCPUTime = 0 then 0 else a.TotalIOCount /(a.AMPCPUTime *1000) end (dec(6,2)) as UII,
MaxAmpCPUTime * (hashamp()+1) as ImpactCPU, a.querytext
FROM SYS_MGMT.dbqlogtbl_hst a
WHERE username=user
AND logdate = :dt
GROUP BY 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18 ,19 ,20,21,22,23 ) as a
LEFT OUTER JOIN SYS_MGMT.dbqlsqltbl_hst s
ON s.ProcID = a.ProcID AND s.QueryID = a.QueryID
AND s.logdate = a.logdate AND substr(sqltextinfo,15001,10) = ''
UNION
SELECT a.UserName,a.LogDate, SessionId,a.ProcId,a.QueryId,a.AcctString , ExpandAcctString ,
DefaultDatabase,SpoolUsage,StartTime, TotalRespTime,
TDWMDelayTime, DelayTime, NumOfActiveAmps, NumResultRows, SumCPU,SumIO,CpuSkw , IOSkw , PJI,UII , ImpactCPU,SqlRowNo,
Case When s.sqltextinfo is not null or s.sqltextinfo = ' ' Then substr(s.SQLTextInfo,1,15000) Else a.querytext End as QryText
FROM ( SELECT a.UserName,a.logdate,a.sessionid ,a.ProcId ,a.QueryId , a.acctstring,a.expandacctstring ,a.defaultdatabase
,a.SpoolUsage, a.Starttime,
((firstresptime-Starttime) day(4) to second) as TotalRespTime,a.DelayTime as TDWMDelayTime , ((firststeptime-Starttime) day(4) to
second) as DelayTime,
NumofActiveAmps, NumResultRows, a.AMPCPUTime as SumCPU ,a.TotalIOCount as SumIO,
Case when (AMPCPUTime / (hashamp()+1) ) =0 then 0 else MaxAmpCPUTimeNorm/(AMPCPUTimeNorm / (hashamp()+1) ) End
(dec(6,2)) as CpuSkw,
Case when (TotalIOCount / (hashamp()+1) ) =0 then 0 else MaxAMPIO/(TotalIOCount / (hashamp()+1) ) End (dec(6,2)) as IOSkw,
Case when a.TotalIOCount = 0 then 0 else (a.AMPCPUTime *1000)/a.TotalIOCount end (dec(6,2)) as PJI,
This is a sample macro that
Case when a.AMPCPUTime = 0 then 0 else a.TotalIOCount /(a.AMPCPUTime *1000) end (dec(6,2)) as UII,
can
be given to adhoc users
MaxAmpCPUTime * (hashamp()+1) as ImpactCPU, a.querytext
FROM SYS_MGMT.dbqlogtbl_dbc a
WHERE username=user
AND logdate = :dt
and developers that has the
GROUP BY 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18 ,19 ,20,21,22,23 ) as a
metrics
for measuring query
LEFT OUTER JOIN SYS_MGMT.dbqlsqltbl_dbc s
performance.
ON s.ProcID = a.ProcID
AND s.QueryID = a.QueryID AND substr(sqltextinfo,15001,10) = ''
ORDER BY 3,10 ; );
39

Teradata Confidential

WORKLOAD MANAGEMENT
DECISIONS

350

300

250

200
150

41

Millions

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Thousands
600

Monday

Post TASM

Monday

Post TASM

Post TASM : More

queries in batch
window

500

400

300

200

100

0
Thursday
Friday

100

50

0
Thursday

Use DBQL to Ensure your

Benchmark comparison
periods
have like characteristics
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Query Counts

Friday

Pre TASM

Teradata Confidential

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Thousands

Benchmarking: Validating System Characteristics

Average Resp Time (Seconds)

16
14
12
10
8
6
4
2
0
Monday

Pre TASM

SumCPU

Monday

Thursday

Post TASM

Post TASM

Friday

Pre TASM

SumIO

1000
900
800
700
600
500
400
300
200
100
0
Thursday
Friday

Pre TASM

Validating Pre and Post Changes by Workload

Pre TASM: Inconsistency
in response time 24x7
even with LOW
concurrency
Pre TASM

600

Post TASM

2.5

500

400

1.5

300

Post TASM: Consistency in

response time 24x7 even
with high concurrency

0.5

100

0
1
2
7
8
9
10
11
12
13
14
15
16
17
18
19
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

0
6/1/2009

6/8/2009

AvgRespTime(Secs)
42

200

Teradata Confidential

# Qrys

No:Of Queries

Response Time (Seconds)

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

Measuring Concurrency
PIT Concurrency

100

90

80

43

Persistent high
concurrency during month
end, which matches high
AWT saturation

70

60

50

40

30

20

10

0
9 10 11 12 13 14 15 16 17 9 10 11 12 13 14 15 16 17 9 10 11 12 13 14 15 16 17 9 10 11 12 13 14 15 16 17
8/9/2010
8/10/2010
Date/Hour/Minute
8/18/2010

Teradata Confidential

8/19/2010

?
Utilities
Penalty-Box
BT_medium
Penalty-Review
BT_low
BT-priHigh
Rush
User_High
BT_high
utilities_ctd
User_Medium
User_Low

Identifying Filters for Errored/Aborted Queries

Using Sum of CPU
Summary for last 14 days by application type

Note: CPU is under reported for

errored and aborted queries. The
CPU for the step that causes the
error or abort is not recorded
44

Teradata Confidential

Identifying Filters for Errored/Aborted Queries

Using Sum of Elapsed Time
Summary for last 14 days by application type

40 Hrs
30 Hrs
20 Hrs
10 Hrs

45

Teradata Confidential

Validating Throttle Adjustments

These Charts show the Average Delay Seconds for all work
that gets delayed. Its an Appliance system with Category 2
throttles for several different workloads
In this case, we needed 2 Charts because of the major
difference in the Y axis values.
Charting Delay Time in this way, allows you to compare how
each group is delayed in relation to others.
160

Average of AvgTDWMDelayTime
1400

Average of AvgTDWMDelayTime

140
1200

120
1000

100
AcctString

800AcctString

$H__ETL&S&D&H
$H__CRM&S&D&H
$H__ARC&S&D&H
$H__ADM&S&D&H

$R__MSP&S&D&H
$R__ETL&S&D&H

80
600

60

46

LogDate

Teradata Confidential

LogDate

8/2/2010

8/1/2010

7/31/2010

7/30/2010

7/29/2010

7/28/2010

7/27/2010

7/26/2010

7/25/2010

7/24/2010

7/23/2010

7/22/2010

7/21/2010

7/20/2010

7/19/2010

7/18/2010

7/17/2010

7/16/2010

7/15/2010

7/14/2010

7/13/2010

7/12/2010

7/11/2010

7/9/2010

8/2/2010

8/1/2010

7/31/2010

7/30/2010

7/29/2010

7/28/2010

7/27/2010

7/26/2010

7/25/2010

7/24/2010

7/23/2010

7/22/2010

7/21/2010

7/20/2010

7/19/2010

7/18/2010

7/17/2010

7/16/2010

7/15/2010

7/14/2010

7/13/2010

7/12/2010

7/11/2010

7/9/2010

200

7/10/2010

20

7/10/2010

400

40

CPU Histogram Bucket Query

Shows number of queries, by account string, based on the amount of CPU used

97.9% use < 1/2 CPU second

99.6% use < 100 CPU seconds
100% use < 200 CPU seconds
10% of Tactical queries used > 1 CPU second
TAC used > 64% of CPU used

Useful to help set up TASM

Indicates if workloads are truly tactical

High priority for queries estimated to use < 1/2 second provides the majority of queries a better opportunity for a good
response time
Medium priority < 100 CPU seconds
Queries > 300 seconds are

Candidates for being demoted or terminated

Exceptions

47

Teradata Confidential

Response Time Histogram

Red areas represent potential areas for

response time improvement through:
Higher priority
Reclassification
Other action

Average response time for each account string and/or workload

Broken down by the amount of CPU used
Classify by CPU buckets that are site appropriate

Queries that use < 1 CPU second have unacceptable response times
Evident in other areas also

Useful information to help set up and analyze TASM

Giving a very high priority for Queries estimated to use less than 1 second should
provide the majority of queries a better opportunity for a good response time

48

Teradata Confidential

Analyzing Exception Log

Use DBQL with DBC.TDWMexceptionLog
Identify queries that are exceptions and possible reasons
Identify time periods that might require Workload adjustments

49

Teradata Confidential

Tactical Application Missing Service Level

Graph shows large increase in number of queries running
longer than one second each day at 3 AM
Work in other workloads impacting this application?
Characteristics of the application work itself changing?
Non-tactical work being done by someone using the Tactical Id?
100%

14000

98%
12000
96%
10000

94%

% of Total

92%
8000
90%
6000
88%

86%

4000

84%
2000
82%

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0
1
2
3
4
5
6
7
8

80%
6/16/2008

6/17/2008

6/18/2008

6/19/2008

Hour

50

Teradata Confidential
Sum of LT_1

Sum of Sec_1_2

Sum of Sec_2_5

Sum of Sec_5_10

Sum of Sec_GT_10

Sum of Count(*)

barbara.christjohn@teradata.com
wendy.hwang@teradata.com

51

Teradata Confidential

BONUS SECTION

Trend Analysis Macro

Replace macro SYS_MGMT.TrendAnalysisDtRng_Rpt ( StartDt DATE, EndDt DATE)
As (SELECT UserName ,acctstring,LogDate, StatementType, AppId
,(substr(cast(Starttime as char(22)),12,2) ) (int) as HR
, count (*) as QryCNT
, sum(a.AMPCPUTime) as SumCPU
, avg(a.AMPCPUTime) as AvgCPU
,max(a.AMPCPUTime) as MaxCPU
, sum(a.TotalIOCOUNT) as SumIO
, avg(a.TotalIOCOUNT) as AvgIO
,max(a.TotalIOCOUNT) as MaxIO
,sum(a.numresultrows) as SumRowsRtnd
,sum(Case when AMPCPUTime < (HashAmp()+1) then 0
when (AMPCPUTime / (HashAmp()+1)) =0 then 0
when (TotalIOCount / (HashAmp()+1)) =0 then 0
when MaxAmpCPUTimeNorm/(AMPCPUTimeNorm / (HashAmp()+1)) > 1.25 /*2.0*/ then AMPCPUTime
when MaxAMPIO/(TotalIOCount / (HashAmp()+1)) > 1.25 /*2.0*/ then AMPCPUTime
when TotalIOCount <> 0 and ((a.AMPCPUTime *1000)/a.TotalIOCount) > 3 then AMPCPUTime
when AMPCPUTime <> 0 and ( a.TotalIOCount/ (a.AMPCPUTime *1000)) > 3 then AMPCPUTime
else 0 end ) as TotPJSkwLgScanCPU
,sum (case when (AMPCPUTime > (hashamp()+1)) then (MaxAmpCPUTime * hashamp()+1)
else AMPCPUTime end) as ImpactCPU
,sum(Case when AMPCPUTime < (HashAmp()+1) then 0
when (AMPCPUTime / (HashAmp()+1)) =0 then 0
when (TotalIOCount / (HashAmp()+1)) =0 then 0
when MaxAmpCPUTimeNorm/(AMPCPUTimeNorm / (HashAmp()+1)) > 1.25 /*2.0*/ then AMPCPUTime
when MaxAMPIO/(TotalIOCount / (HashAmp()+1)) > 1.25 /*2.0*/ then AMPCPUTime
else 0 end ) as SkwdQryCPU
,sum(Case when AMPCPUTime > (HashAmp()+1) and TotalIOCount <> 0 and ((a.AMPCPUTime *1000)/a.TotalIOCount) > 3
then AMPCPUTime else 0 End) as PJQryCPU
,sum(Case when AMPCPUTime > (HashAmp()+1) and AMPCPUTime <> 0 and (a.TotalIOCount/ (a.AMPCPUTime *1000)) > 3
then AMPCPUTime else 0 End) as LgScanCPU
,Avg(Case when DelayTime > 0 then DelayTime else null end) as AvgTDWMDelayTime
,Sum(DelayTime) as SumTDWMDelayTime
,Zeroifnull(cast(avg ( CAST(extract(hour
From
((a.Firstresptime - a.StartTime) HOUR(2) TO SECOND(2) ) ) * 3600 + extract(minute
From
((a.Firstresptime - a.StartTime) HOUR(2) TO SECOND(2) ) ) * 60 + extract(second
From
((a.Firstresptime - a.StartTime) HOUR(2) TO SECOND(2) ) ) AS Decimal(10,2)) ) AS Decimal(10,2)))
As AvgRespTimeSecs
from sys_mgmt.DBQLogTbl_hst a
WHERE LogDate between :Startdt and :enddt
GROUP BY 1,2,3 ,4,5, 6
53
Teradata Confidential
ORDER BY 1,2,3 ;
);

Suspect Query Macro

Replace Macro SYS_MGMT.SuspQuerysDtRng_Rpt (Startdt date, enddt date, topN int)
as (
SELECT Rank(ImpactCPU) as CPURank
,UserName ,AcctString ,StatementType,ExpandAcctString ,appid,clientid
,DefaultDatabase, SpoolUsage ,StartTime,ParseDictTime,QryRespTime
, NumOfActiveAmps, NumResultRows ,SumCPU, SumIO ,CpuSkw ,IOSkw ,PJI ,UII ,ImpactCPU
,Case When s.sqltextinfo is not null or s.sqltextinfo = ' ' Then s.SQLTextInfo||';'
Else a.querytext||';' End as QryText
FROM (select a.UserName , a.ProcId , a.QueryId , a.expandacctstring ,appid ,clientid
, CAST(extract(hour
From
((a.firststeptime - a.StartTime) HOUR(2) TO SECOND(2) ) ) * 3600 + extract(minute
From
((a.firststeptime - a.StartTime) HOUR(2) TO SECOND(2) ) ) * 60 + extract(second
From
((a.firststeptime - a.StartTime) HOUR(2) TO SECOND(2) ) ) AS INTEGER) as ParseDictTime
,((firstresptime-Starttime) day(4) to second) as QryRespTime, NumofActiveAmps, NumResultRows
, a.AMPCPUTime as SumCPU , a.TotalIOCount as SumIO
,Case when AMPCPUTime < 1 or (AMPCPUTime / (HashAmp()+1)) =0 then 0
else MaxAmpCPUTimeNorm/(AMPCPUTimeNorm / (HashAmp()+1)) End (dec(8,2)) as CPUSKW
,Case when AMPCPUTime < 1 or (TotalIOCount / (HashAmp()+1)) =0 then 0
else MaxAMPIO/(TotalIOCount / (HashAmp()+1)) End (dec(8,2)) as IOSKW
,Case when AMPCPUTime < 1 or TotalIOCount = 0 then 0 else (a.AMPCPUTime *1000)/a.TotalIOCount end as PJI
,Case when AMPCPUTime < 1 or AMPCPUTime = 0 then 0 else a.TotalIOCount/(a.AMPCPUTime *1000) end as UII
, a.MaxAmpCPUTime * (hashamp()+1) /*no. of Amps*/ as ImpactCPU, a.acctstring , a.Starttime , a.querytext , a.logdate ,
a.defaultdatabase , a.SpoolUsage, StatementType
from sys_mgmt.DBQLogTbl_hst a
WHERE logdate between :Startdt and :enddt
and (SumCPU > 1 * (hashamp()+1) /* I use this threshold because smaller queries are often not Suspect Queries*/
and( (CpuSkw > 1.25 or IOSkw > 1.25 )
or UII > 3
/* UnNecessary IO Indicator - may offer an opportunity for Indexing */
or pji > 3
/* Could use a higher threshold (6) for 5200 and older systems */
)) group by 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 ) as a
left outer join (Select Procid, Queryid, logdate, substr(sqltextinfo,1,15000) as sqltextinfo
from SYS_MGMT.DBQLSQLTbl_hst s
WHERE logdate between :Startdt and :enddt
and sqlrowno = 1) as s
on s.ProcID = a.ProcID
and s.QueryID = a.QueryID
and s.logdate = a.logdate
qualify Rank(ImpactCPU) <= :TOPN
ORDER BY 1; );
54

Teradata Confidential

Teradata XML Services: Where to get

started

Teradata XML Services Release 1 Users Guide Orange Book

OS and DB versions supported for latest release (1.1.7)

MPRAS and Windows 32-bit DB v2R6.1, 6.2, 12.0

SLES 10 DB v2R6.2, 12.0, 13.0

Feature is distributed as a download at

http://www.teradata.com/DownloadCenter/Forum127-1.aspx

55

Teradata Confidential