Information Products Home > Teradata Database, Tools and Utilities Release 14.00

Search Tips

General Reference

SQL Reference

Database Management

Application Programming ReferenceWorkload Management

Data Dictionary

Database Administration

Preface

Getting Started with TeradataDatabase

Populating the Database

Users, Roles, and Profiles

Space

Data Dictionary Tables and Views

Privileges

Sessions and Accounts

Using Account String Expansion

Protecting Data

Archiving, Restoring, and RecoveringData

Stopping and Restarting the System

Recommended Housekeeping Tasks

Managing Database Resources

Tracking Processing Behavior withDBQL

Troubleshooting

Handling Teradata Crashdumps

Teradata Database Configuration,Global Defaults, and ClientConnections

Import/Export Utilities

Performance Management

Implementing PerformanceManagement

About Performance ManagementSetup

Monitoring the System

Collecting Statistics

Setting Up Database Query Logging

Managing Query Performance

Finding and Fixing Problem Queries

Managing Skewed Processing

Identifying and Fixing Skewed Tables

Identifying and Managing BlockedQueries

Working with Transaction Rollbacks

Managing the Database Workload

Managing Database Resources toEnhance Performance

Performance and Space Management

Performance and MemoryManagement

Periodic Maintenance and Performance

Capacity Planning

Performance Considerations whenExpanding or Upgrading the DatabaseSystem

Error Logs

Database Administration > Performance Management > Finding and Fixing Problem Queries

Finding and Fixing Problem Queries

You can use the Teradata Viewpoint Query Monitor portlet for regular monitoring of database queries and to investigate whether a reported delay is the result of a badquery.

Note: The Query Monitor portlet has many functions beyond what is shown in this example procedure. See Teradata Viewpoint User Guide for detailed setup and options.

1 Monitor query activity using the By Session tab.

2 Look for bad queries using the following Query Monitor parameters: High CPU Use% combined with low REQ I/O accesses. If the CPU divided by the I/0 is > 100, the query is probably bad.

High CPU Skew% with significant Delta CPU.

High spool usage.

Note: You can click on and sort the display by a parameter instead of by session number.

3 Select a session row that shows CPU characteristics indicating a bad query to display the Details View, which provides information about the query, including the userand account that submitted the query.

4 Select the SQL tab to display the query. Examine the SQL for errors and poor construction.

5 Select the Explain tab to display an abbreviated version of the step statistics and explain text (generated from a full EXPLAIN request), along with a listing of the activesteps, completed steps, and steps yet to run.

6 Check for the following in the Explain: The steps required to execute the query

The type of operation being performed, and whether it includes a product join

Often the query is stuck on the step where the product join occurs.

7 You can copy the query from the SQL tab, run it from Teradata SQL Assistant, and request a full EXPLAIN to get more details and validate the source of the problem.

8 If the query appears to be constructed correctly, other problems may be indicated. System conditions may cause uneven processing. See Skewed Query Processing Across Nodes and Skewed Query Processing Across AMPs.

The data table may have skewed distribution. See Identifying and Fixing Skewed Tables .

The query may be blocked from accessing the data. See the sections beginning with Identifying and Managing Blocked Queries .

If a bad query causes problems in the database, you can:

Use Query Monitor to abort the query. See Teradata Viewpoint User Guide.

Use the SET SESSION ACCOUNT request to reassign a poorly-performing query to a lower priority account. For information on:

Using accounts to set job priorities, see Account Strings and Performance Groups.

SET SESSION ACCOUNT, see SQL Data Definition Language Syntax and Examples.

Alternate Query Investigation Methods

Problem Action

If the system is CPU-bound ordisk-bound, or the processing isskewed.

Look at physical resource utilization:

Use Teradata Viewpoint. Monitor physical resources to viewCPU/disk usage by node. Monitor virtual resources to view CPU/diskusage by vproc.

Look at DBC.ResusageSpma to view CPU, disk, and BYNET usage.

Look at workload utilization:

Use DBQL to find the user with the skewed processing.

Look at data distribution:

Use DBC.TableSizeV to identify tables with skewed data distribution.

If the processing is skewed,identify the user.

Use Teradata Viewpoint.

Check DBC.SessionInfoV or run Query Session to identify the currentuser.

Check DBC.LogOnOffV to view historical users.

Check DBC.AMPUsage to identify the heavy resource user.

Check DBC.DiskSpaceV to identify large spool user.

If the processing is skewed, getinformation on the problematicquery.

To identify the query, ask the user or check query log.

Run EXPLAIN on the query to determine if a bad join plan exists. Look forunexpected product joins. Verify that large tables are not joined beforesmall tables. Look for estimates that are too high or too low.

Copyright 1998-2013 by Teradata Corporation. All Rights Reserved.

Finding and Fixing Problem Queries http://www.info.teradata.com/htmlpubs/DB_TTU_14_00/index.html#pag...

1 of 2 12/28/2014 7:20 PM

Database Design

Resource Usage Macros and Tables

Security Administration

SystemFE Macros

Utilities

Replication Services

International Character Set

Connectivity

Interface Tools

Storage Management

Load and Unload Utilities

Finding and Fixing Problem Queries http://www.info.teradata.com/htmlpubs/DB_TTU_14_00/index.html#pag...

2 of 2 12/28/2014 7:20 PM