Teradata 2690 Data Warehouse Appliance Implementation Guide

Teradata Data Warehouse Appliance 2690
Implementation Guide
Release 14.0
B035-1195-042K
September 2013
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, Active Data Warehousing, 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.
Apple, Mac, and OS X all are registered trademarks of Apple Inc.
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.
Quantum and the Quantum logo are trademarks of Quantum Corporation, registered in the U.S.A. and other countries.
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: [email protected].
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 © 2000-2013 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
This guide describes the minimum tasks required to implement database operations on the
Teradata Data Warehouse Appliance 2690, including:
•
Configuring the system and its connected clients
•
Monitoring the health of system hardware and handling common problems
•
Converting existing database table definitions and queries to Teradata SQL
•
Moving data from an existing database into Teradata Database
•
Creating Teradata Database users, roles and profiles
•
Granting database access privileges, logging access attempts, and auditing security logs
•
Monitoring and managing database activity, performing periodic maintenance, and using
performance tuning features
Reference information tables appear at the end of many procedures that provide links to
additional capabilities and options.
Audience
This guide is intended for first time users of Teradata Database:
•
Planners
•
Administrators
•
System programmers
Supported Software Release
This books supports Teradata database 14.0 running on a Teradata Data Warehouse Appliance
2690.
Teradata Data Warehouse Appliance 2690 Implementation Guide
3
Preface
Changes to This Guide
Changes to This Guide
This guide includes the following changes to support the current release:
Release
Description
Teradata Database 14.0
• Clarified that Teradata Active System Management (TASM) is not
available for Teradata Data Warehouse Appliance 2690. The
available filters and throttles are part of Teradata Workload
Management.
• Updated the discussion in Chapter 13 on Managing the Database
with Teradata Workload Management.
• Updated the URL for Teradata @ Your Service.
September 2013
Additional Information
URL
Description
www.info.teradata.com/
Use the Teradata Information Products Publishing Library
site to:
• View or download a manual:
1 Under Online Publications, select General Search.
2 Enter your search criteria and click Search.
• Download a documentation CD-ROM:
1 Under Online Publications, select General Search.
2 In the Title or Keyword field, enter CD-ROM, and
click Search.
• Order printed manuals:
Under Print & CD Publications, select How to Order.
www.teradata.com
The Teradata home page provides links to numerous
sources of information about Teradata. Links include:
• Executive reports, case studies of customer experiences
with Teradata, and thought leadership
• Technical information, solutions, and expert advice
• Press releases, mentions and media resources
4
www.teradata.com/t/TEN/
Teradata Customer Education designs, develops and
delivers education that builds skills and capabilities for
our customers, enabling them to maximize their Teradata
investment.
https://tays.teradata.com
Use Teradata @ Your Service to access Orange Books,
technical alerts, and knowledge repositories, view and join
forums, and download software patches.
Teradata Data Warehouse 2690 Implementation Guide
Preface
References to Linux and Windows
URL
Description
developer.teradata.com/
Teradata Developer Exchange provides articles on using
Teradata products, technical discussion forums, and code
downloads.
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 e-mail: [email protected].
References to Linux and Windows
This guide makes various references to “Linux” and “Windows.”
•
The Teradata Data Warehouse Appliance 2690 runs on SUSE Linux Enterprise Server 10,
Service Pack 3, which is referred to in the text as “Linux.”
•
Although Teradata Database supports several client operating systems, this guide assumes
that Teradata clients run a supported version of Microsoft Windows. The general term
“Windows” is used except in cases where a reference is dependent on a specific version of
Microsoft Windows.
Teradata Data Warehouse Appliance 2690 Implementation Guide
5
Preface
References to Linux and Windows
6
Teradata Data Warehouse 2690 Implementation Guide
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Supported Software Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Changes to This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
References to Linux and Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Chapter 1: Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Organization of This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Database Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
SECTION 1
System Configuration
Chapter 2: System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Cabinet Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cabinet Component Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customer Network and Mainframe Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Data Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
21
25
28
28
29
Teradata Database Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Parallel Database Extensions (PDE). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Teradata Database Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Teradata Data Warehouse Appliance 2690 Implementation Guide
7
Table of Contents
Chapter 3: Setting Up System Management . . . . . . . . . . . . . . . . . . . .35
SMWeb Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Configuring a Workstation for Use with SMWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Setting Up an Internet Explorer Browser on a Windows Workstation . . . . . . . . . . . . . . .37
Setting Up a Firefox Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Setting Up Software on a Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Accessing the SMWeb Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Navigating to the SMWeb Home Page from the SOV CMIC . . . . . . . . . . . . . . . . . . . . . . .38
Navigating to the SMWeb Home Page from a Non-SOV CMIC . . . . . . . . . . . . . . . . . . . .39
Setting Up User Access to SMWeb Applications and Web Pages . . . . . . . . . . . . . . . . . . . . . . .39
Adding a User, Enhanced User, or Service User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Setting Up Server Management Command Line Interface Utilities. . . . . . . . . . . . . . . . . . . . . .41
Setting Up SMWeb CLI Utilities on a Windows Workstation . . . . . . . . . . . . . . . . . . . . . .41
Setting Up SMWeb CLI Utilities on a Linux Workstation. . . . . . . . . . . . . . . . . . . . . . . . . .42
Setting Up an Alert Subscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
About SNMP Trap Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Creating an Alert Subscription for SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Retrieving the SNMP Trap Definition (MIB File) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
SNMP Trap Definitions in the SMAlertingMIB.txt File. . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Working with SMClient Default Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Setting Up SMClient Default Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
SMClient Default Views Used to Monitor the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Monitoring System Health with SMClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Monitoring the Alert Viewer for System Alerts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Determining When to Take Action to Fix a Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Working with Customer-Replaceable Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Preparing to Replace a Problem Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Opening a Maintenance Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Closing a Maintenance Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Determining Whether Your Action Solved the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Opening an Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
When to Open an Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Gathering Needed Supporting Information for an Incident . . . . . . . . . . . . . . . . . . . . . . . .59
Opening Incidents Through Teradata @ Your Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Chapter 4: Setting Up Teradata Clients . . . . . . . . . . . . . . . . . . . . . . . . . . .63
About Client Software Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
8
Teradata Data Warehouse Appliance 2690 Implementation Guide
Table of Contents
Installation Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard Client Software Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optional Client Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Software Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
64
64
64
64
Installing Microsoft .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Installing Teradata Tools and Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Using the Latest Software Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Downloading the Latest Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Installing the Latest Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Downloading the Windows Help Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configuring Network Name Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Creating Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Working with ODBC Data Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Setting up Teradata as an ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Setting Up an External ODBC Data Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Restarting the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Setting Up Teradata Clients to Access Teradata Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Prerequisites for Setting up Teradata Viewpoint on Clients . . . . . . . . . . . . . . . . . . . . . . . 75
Requirements for Viewpoint Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
SECTION 2
Database Implementation
Chapter 5: Setting up Administrative Users . . . . . . . . . . . . . . . . . . . . 79
Implementation Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Configuring Default Administrative Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up the Teradata Administrator GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Data Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Global Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Lock Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the PasswordExpire Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
79
80
80
81
81
Allocating Space for System-Level Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About Database Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About System-Generated Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Required System-Level Space Allocation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Spool Space Reserve. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assigning Perm Space to Crashdumps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
83
83
84
84
85
Teradata Data Warehouse Appliance 2690 Implementation Guide
9
Table of Contents
Setting Up the Database Administrator User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Required Database Administrator Setup Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Creating the DBADM Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Creating User DBADMIN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Granting Database Privileges to User DBADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Setting Up Database Administrator Access to Teradata Viewpoint . . . . . . . . . . . . . . . . . .96
Chapter 6: Creating the Database Structure . . . . . . . . . . . . . . . . . . . .99
Database Implementation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
About the Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Working with Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
About Top Level Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Creating the Tables Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Creating the Views Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Working with Table Access Privileges for Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Working with Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
About Teradata Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Converting Existing Database Tables to Teradata Tables . . . . . . . . . . . . . . . . . . . . . . . . .107
About Primary Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Choosing a Primary Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Creating Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Validating Primary Index Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Working with Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Creating Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Working with the Basic Teradata Query Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Starting BTEQ in Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Using BTEQ Scripts to Create Database Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Chapter 7: Converting Queries to Teradata SQL . . . . . . . . . . . . . . .125
Converting Data Types to Teradata Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Converting Built-in SQL Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
About Oracle-Equivalent Teradata UDFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Installing Oracle-Equivalent Teradata UDFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Using Oracle-Equivalent Teradata UDFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Translating Built-in SQL Functions to Teradata SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Converting Hierarchical Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Converting Outer Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
10
Teradata Data Warehouse Appliance 2690 Implementation Guide
Table of Contents
Checking the Use of NULLs in Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Converting Nested Aggregate Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Converting External Tables to Table Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Converting Queue Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Converting Queries to Set Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Converting PL/SQL Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
General Considerations for Using Teradata SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 8: Querying the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Working with SQL Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Invoking SQL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Single and Multistatement Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About Differences Between Teradata SQL and ANSI SQL . . . . . . . . . . . . . . . . . . . . . . .
About Session Modes and Transaction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction Processing in ANSI Session Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction Processing in Teradata Session Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting the Session Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
139
139
140
141
142
143
143
144
Using SQL Assistant to Submit a Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Executing a Query Using SQL Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Executing Multiple SQL Statements in Parallel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Working with Commonly Used Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the SELECT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the INSERT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the UPDATE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the DELETE Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
147
147
147
148
148
Working with Macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Creating Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Working with Database Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About Locks and Lock Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Default Lock Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring and Managing Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
153
153
155
156
Chapter 9: Optimizing Query Performance . . . . . . . . . . . . . . . . . . . . . 159
Using COLLECT STATISTICS to Optimize Query Performance . . . . . . . . . . . . . . . . . . . . .
About Statistics Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to Collect Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Teradata Data Warehouse Appliance 2690 Implementation Guide
159
159
160
160
11
Table of Contents
Stale Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
Recollecting Statistics when Existing Statistics Are Stale . . . . . . . . . . . . . . . . . . . . . . . . . .161
Using EXPLAIN to Analyze Query Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
About the EXPLAIN Request Modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Generating an EXPLAIN with SQL Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Generating an EXPLAIN with BTEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Using Indexes to Improve Query Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
About Indexing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Costs and Benefits of Secondary Indexes and Join Indexes . . . . . . . . . . . . . . . . . . . . . . . .164
About Secondary Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Choosing a Secondary Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Creating Secondary Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Join Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Validating and Maintaining Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
Chapter 10: Setting Up Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
User Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
About User Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Determining Database User Needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
Working with User Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
About Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Creating Account Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
Determining the Account for a User Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
Working with Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
About Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
Creating Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
Working with Database Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
About Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Creating Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Using Roles to Manage User Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
User Types and Minimum Required Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Types of Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
Privileges That Must Be Explicitly Granted. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Creating User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Granting Privileges to a Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Granting User Membership in a Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Defining the Default Role for a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Granting Privileges Directly to Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Granting Privileges on Sys_Calendar to All Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Granting Privileges to a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
12
Teradata Data Warehouse Appliance 2690 Implementation Guide
Table of Contents
SECTION 3
Database Administration
Chapter 11: Monitoring User Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
About Access Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Default Access Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Common Access Logging Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Setting Up Access Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the DIPACC Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the BEGIN LOGGING Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Access Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
198
198
198
199
Disabling Access Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Using Access Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
About Access Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Auditing Database Activity Using DBC Log Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Chapter 12: Monitoring the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
About Viewpoint Monitoring Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Setting Up Teradata Viewpoint Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Working with User Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Creating a Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Using Viewpoint Alerts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Setting Up Alert Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Creating Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Chapter 13: Managing the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
About Space Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Compressing Data to Save Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Multi-Value Compression (MVC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Algorithmic Compression (ALC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Hash Index and Join Index Row Compression . . . . . . . . . . . . . . . . . . . . . . . . . . .
About Block Level Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Block Level Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Updating Space Accounting for BLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
217
218
218
218
219
219
220
Identifying and Correcting Space Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Teradata Data Warehouse Appliance 2690 Implementation Guide
13
Table of Contents
Identifying Space Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Reallocating Perm Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
Increasing the Spool Space Limit for a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
Finding and Fixing Skewed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
Setting Up Teradata Viewpoint Alerts for Space Usage . . . . . . . . . . . . . . . . . . . . . . . . . . .224
Managing Query Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
About Common Query Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
Setting Up Lock Logging Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
Identifying Bad Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
Controlling Bad Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
About Lock Contentions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
Investigating Query Blocks and Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
Using Performance Groups to Manage Job Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
How the System Determines the Session Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
System Enforced Job Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
CPU Milestones for Performance Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Checking Priority Scheduler Settings and Usage with schmon . . . . . . . . . . . . . . . . . . . . .231
Finding All Accounts with a Rush Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
Changing the Priority Level for a Session or Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
Disabling and Re-enabling CPU Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Managing the Database with Teradata Workload Management . . . . . . . . . . . . . . . . . . . . . . .234
Determining Workload Management Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Defining a Teradata Workload Management Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Chapter 14: Maintaining the Database . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Teradata Database Console Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Running Database Utilities From Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Running Database Utilities from cnsterm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
Running Database Utilities from a Database Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Database Maintenance Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Managing Accumulated Log Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
About Database Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
Deleting Old Log Data with Teradata Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Deleting Old Log Data Manually from System Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Verifying Data Block Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Running SCANDISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Running CheckTable at Level 2 for Database DBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
Running CheckTable at Level 1 for Non-DBC Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Restarting the Teradata Database Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
Initiating a Manual Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
14
Teradata Data Warehouse Appliance 2690 Implementation Guide
Table of Contents
About Automatic Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Troubleshooting Database Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Upgrading Teradata Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Powering the System Off and On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Powering Off All Chassis in a System or Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Powering On All Chassis in a System or Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Servicing Unplanned Power Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Chapter 15: Moving Data To and From Teradata
Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Data Movement Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
About Teradata Parallel Transporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
About TPT Easy Job Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
TPT Job Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
About TPT Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Using Global Job Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Setting Up the Global Job Variables File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Loading a Data From an External ODBC Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Notes for Loading a Teradata Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Job Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Local Job Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Considerations When Importing Data From an ODBC Database. . . . . . . . . . . .
266
266
266
267
270
Loading Data from an External Flat File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Notes for Loading a Teradata Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Job Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Local Job Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
271
271
272
272
Exporting Data to an External Flat File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Notes for Exporting Data to a Flat File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating an Export Job Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Local Job Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
275
275
275
276
Launching a Teradata PT Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Specifying Job Variables at Job Launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Monitoring and Managing a Teradata PT Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pausing and Resuming a Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing the Job Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminating a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
279
279
279
280
Evaluating a Completed Teradata PT Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Examining the Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Troubleshooting a Failed Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Teradata Data Warehouse Appliance 2690 Implementation Guide
15
Table of Contents
Appendix A: Type and Format Differences Between
Teradata and Other DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
About Teradata Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
DATE Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Geospatial Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
User-Defined Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
Appendix B: Loading and Updating Tables with BTEQ . . . . . . . .287
Differences Between BTEQ and Teradata PT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Loading Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Updating Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Updating Rows Using a Single Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Updating Rows Using Multiple Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Updating Rows by Importing a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Using the REPEAT Command When Importing a File . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Appendix C: Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
About Procedures and External Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Differences Between Macros and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
User-Defined Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
16
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 1
Introduction
This guide documents standard best practices for implementing a Teradata Data Warehouse
Appliance 2690 system. Actual implementations may vary according to individual site
requirements.
Assumptions
The implementation procedures shown in this guide are based on the following assumptions:
•
Teradata Customer Service has performed the standard installation and basic
configuration services.
•
The site has a Core Support (or higher) agreement with Teradata Customer Service.
•
Any existing customer data that is to be moved into the Teradata Data Warehouse
Appliance 2690 system is stored in an ODBC-compliant database or in flat files.
•
The procedures in this book assume authentication of database users by Teradata Database
(TD 2 mechanism). If your site security policy requires users to be authenticated by an
external agent, for example Kerberos or LDAP, see Security Administration for setup and
logon instructions.
•
Although Teradata clients can run on a number of operating systems, the examples
presented are based on clients running a supported version of Windows.
Note: Additional assumptions and prerequisites appear in the text for individual tasks.
Organization of This Book
This implementation guide is divided into four sections, which provide basic instructions for
the four phases of Teradata Data Warehouse Appliance 2690 implementation and operation:
•
System Configuration includes Chapters 2-4. Describes system components and systemlevel setup tasks you must perform.
•
Database Configuration includes Chapters 5-10. Describes how to design, create, and
configure the database objects and processes necessary for database operation.
•
Database Administration includes Chapters 11-15. Describes how to setup and perform
database administration and maintenance tasks.
Note: For initial implementation, perform the tasks in Chapters 2 through 13 in the order
shown, unless otherwise directed in the text.
Teradata Data Warehouse Appliance 2690 Implementation Guide
17
Chapter 1: Introduction
Database Implementation Process
Database Implementation Process
System Configuration
•
•
Chapter 2
System Components
Hardware configuration
Software components
Chapter 3
Setting Up System Management
• Configure system monitoring
• Fix problems and open incidents
Chapter 4
Setting Up Teradata Clients
•
•
18
Install/configure client software
Connect clients to the database
Database Administration
Database Configuration
Chapter 5
Setting up Administrative Users
• Allocate system disk space
• Create /provision administrators
•
•
Chapter 6
Creating the Database Structure
Create tiered database architecture
Design effective indexing
Chapter 7
Converting Queries to Teradata SQL
• Convert data types/tables/joins
• Convert SQL functions and other
database operations
•
•
Chapter 8
Querying the Database
Create and submit queries
Understand and work with locks
•
•
•
Chapter 9
Optimizing Query Performance
Collect and analyze statistics
Analyze the EXPLAIN
Use secondary and join indexes
•
•
Chapter 10
Setting Up Users
Create users, roles, and profiles
Assign user privileges
Chapter 11
Monitoring User Activity
•
•
Log user access attempts
Monitor access logs to detect issues
•
•
Chapter 12
Monitoring the Database
Set up Viewpoint users
Set up dashboards and alerts
•
•
•
Chapter 13
Managing the Database
Find and correct space problems
Find and manage bad queries
Assign/manage workload priorities
•
•
•
•
Chapter 14
Maintaining the Database
Running database utilities
Managing accumulated log data
Restarting the database
Powering Off/On the System
•
•
•
Chapter 15
Moving Data To and From
Teradata Database Tables
Create the Configuration files
Create load and export job scripts
Launch and manage a job
•
Evaluate and troubleshoot a job
Teradata Data Warehouse Appliance 2690 Implementation Guide
SECTION 1
System Configuration
Teradata Data Warehouse Appliance 2690 Implementation Guide
19
Section 1: System Configuration
20
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 2
System Components
This section presents an overview of the Teradata Data Warehouse Appliance 2690 system.
Hardware Components
This section provides hardware component information for one configuration of the Teradata
Data Warehouse Appliance 2690 system, in which:
•
The system can grow to a maximum of 46 processing nodes
•
Internal system communication uses the BYNET-over-Ethernet protocol
For information about other system configurations, see the Teradata Data Warehouse
Appliance 2690 Platform Product and Site Preparation Guide.
Hardware components are housed in Teradata platform cabinets. Every platform cabinet
contains the following hardware:
•
•
A maximum of four cliques. Each clique consists of:
•
Two processing (Teradata Database) nodes
•
One disk array (each disk array is made up of two drive enclosures; one enclosure with
controllers and one enclosure with ESMs)
One virtualized management server (VMS):
•
Processing/storage cabinet 1 contains a System VMS, hosting the CMIC, SWS, and
Viewpoint virtual machines (VMs)
•
Each additional processing/storage cabinet contains a Cabinet VMS, hosting only the
CMIC VM
•
Two 1-Gigabit Ethernet BYNET switches
•
Two 1-Gigabit Ethernet server management switches
•
Two AC boxes
•
One keyboard/video/mouse (KVM) unit in processing/storage cabinet 1
•
Up to six Teradata managed servers (BAR, Viewpoint, SAS, etc.), channel servers, or
extended channel solution (ECS) servers may be in each processing/storage cabinet
For component information, see “Cabinet Component Descriptions” on page 25.
Example Cabinet Configurations
The following sections show the standard component arrangement for fully populated
Teradata Data Warehouse Appliance 2690 cabinets. Actual deployed cabinets may contain
fewer components than shown, depending on system configuration.
Teradata Data Warehouse Appliance 2690 Implementation Guide
21
Chapter 2: System Components
Hardware Components
Processing/Storage Cabinet 1 with 1 Clique and 6 TMSs
2 24-port 1 Gb
Ethernet switches
for server management
(chassis 1 and 21)
21
Secondary SM Switch
Maximum configuration:
up to 4 cliques in cabinet;
up to 6 TMSs, channel servers
or ECS servers in cabinet
Each clique consists
of 2 processing nodes
and 1 disk array
1 VMS per cabinet
2 48-port 1 Gb BYNET Enet
switches or 2 BYA32S BYNET
V4 switches (chassis 10 and 11)
16
TMS / Channel Server / ECS
15
TMS / Channel Server / ECS
14
TMS / Channel Server / ECS
13
TMS / Channel Server / ECS
12
VMS
11
BYNET-1 Switch
cable manager
10
BYNET-0 Switch
1 KVM in first cabinet
2 AC boxes per cabinet
Each disk array consists
of 2 drive enclosures:
1 enclosure with controller
and 1 enclosure with ESM
KVM
7
Drive Enclosure with ESM
(first clique)
6
Drive Enclosure with Controller
(first clique)
5
TMS / Channel Server / ECS
4
TMS / Channel Server / ECS
3
Node
(first clique)
2
Node
(first clique)
1
Primary SM Switch
AC
Box
AC
Box
#
managed chassis
#
unmanaged chassis
components loaded/accessible
from rear of cabinet
Cabinet_0263
22
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 2: System Components
Hardware Components
Processing/Storage Cabinet 1 with 4 Cliques
2 24-port 1 Gb
Ethernet switches
for server management
(chassis 1 and 21)
21
Secondary SM Switch
20
Drive Enclosure with ESM
(fourth clique)
19
Drive Enclosure with Controller
(fourth clique)
18
Drive Enclosure with ESM
(third clique)
17
Drive Enclosure with Controller
(third clique)
16
Node
(fourth clique)
15
Node
(fourth clique)
14
Node
(third clique)
13
Node
(third clique)
1 VMS per cabinet
12
VMS
2 48-port 1 Gb BYNET Enet
switches or 2 BYA32S BYNET
V4 switches (chassis 10 and 11)
11
BYNET-1 Switch
Each clique consists
of 2 processing nodes
and 1 disk array
Each disk array consists
of 2 drive enclosures:
1 enclosure with controller
and 1 enclosure with ESM
cable manager
10
BYNET-0 Switch
KVM
1 KVM in first cabinet
2 AC boxes per cabinet
Maximum configuration:
up to 4 cliques in cabinet;
up to 6 TMSs, channel servers
or ECS servers in cabinet
9
Drive Enclosure with ESM
(second clique)
8
Drive Enclosure with Controller
(second clique)
7
Drive Enclosure with ESM
(first clique)
6
Drive Enclosure with Controller
(first clique)
5
Node
(second clique)
4
Node
(second clique)
3
Node
(first clique)
2
Node
(first clique)
#
managed chassis
1
Primary SM Switch
#
unmanaged chassis
AC
Box
AC
Box
components loaded/accessible
from rear of cabinet
Cabinet_0262
Teradata Data Warehouse Appliance 2690 Implementation Guide
23
Chapter 2: System Components
Hardware Components
Processing/Storage Cabinets 2+ with 4 Cliques and 2 TMSs
2 24-port 1 Gb
Ethernet switches
for server management
(chassis 1 and 21)
1 VMS per cabinet
2 AC boxes per cabinet
21
Secondary SM Switch
20
Drive Enclosure with ESM
(fourth clique)
19
Drive Enclosure with Controller
(fourth clique)
18
Drive Enclosure with ESM
(third clique)
17
Drive Enclosure with Controller
(third clique)
16
Node
(fourth clique)
15
Node
(fourth clique)
14
Node
(third clique)
13
Node
(third clique)
12
VMS
11
TMS / Channel Server / ECS
10
TMS / Channel Server / ECS
9
Drive Enclosure with ESM
(second clique)
8
Drive Enclosure with Controller
(second clique)
7
Drive Enclosure with ESM
(first clique)
6
Drive Enclosure with Controller
(first clique)
5
Node
(second clique)
4
Node
(second clique)
3
Node
(first clique)
2
Node
(first clique)
#
managed chassis
1
Primary SM Switch
#
unmanaged chassis
AC
Box
maximum configuration:
up to 4 cliques in cabinet;
up to 6 TMSs, channel servers
or ECS servers in cabinet
each clique consists
of 2 processing nodes
and 1 disk array
each disk array consists
of 2 drive enclosures:
1 enclosure with controller
and 1 enclosure with ESM
AC
Box
components loaded/accessible
from rear of cabinet
Cabinet_0279
24
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 2: System Components
Hardware Components
Cabinet Component Descriptions
The following table describes the Teradata Data Warehouse Appliance 2690 components
shown in “Example Cabinet Configurations.”
Component
Description
Node
Cabinets contain two processing nodes per clique. Each node is made up of one Dell R710
chassis with:
• Two six-core Intel Xeon X5675 processors (12 MB cache, 3.06 GHz)
• 96 GB memory using 8 GB DIMMs
• Disk drives:
• Two 450 GB SAS (serial attached SCSI) drives for OS
• One 450 GB SAS drive for dump processing to improve restart performance
• Three additional drive bays available for customer use; 450 GB drives supported
• DVD+RW drive
• Onboard connectivity to the server management network
• Onboard connectivity to the BYNET-over-Ethernet network
• Disk storage adapter
• Compression engine adapters
• Optional network communication adapter
• Teradata Database 14.0 software
• SUSE Linux Enterprise Server 10 (SLES10) SP3 operating system
Disk Array
Cabinets contain one disk array per clique. Each disk array consists of two 5350 Camden
drive enclosures. Each drive enclosure contains:
• Two controller modules or two ESMs
• Two power supply/cooling modules
• Twenty-four 2.5” 10K rpm SAS storage drives, available in 300GB, 600GB, and 900 GB
capacities
Channel Server
Dell R710 chassis, configured as dedicated server for interface between Teradata Database
and IBM (or compatible) mainframe:
• Single Intel 2.4 GHz quad-core CPU
• 24 GB memory (using 4 GB DIMMs)
• Host channel adapters -- maximum three FICON and/or ESCON adapters (can mix
types in same node)
• No disk array support
• No amps assigned
• Onboard connectivity to the server management network
• Onboard connectivity to the BYNET-over-Ethernet network
• Optional network communication adapter
Teradata Data Warehouse Appliance 2690 Implementation Guide
25
Chapter 2: System Components
Hardware Components
Component
Description
(Virtualized Management
Server) VMS
The VMS is available in System VMS and Cabinet VMS configurations and can host the
following virtual machines (VMs):
• CMIC -- The CMIC provides server management services for the system cabinets.
• SWS -- The SWS is the service entry for the system.
• Viewpoint -- The Viewpoint VM manages only a single Teradata system.
Each System VMS consists of:
• CMIC, SWS, and Viewpoint VMs
• Intel SR1625 chassis
• Two Intel 2.4 GHz quad-core CPUs
• 24 GB memory using 4 GB DIMMs
• Two 300 GB RAID 1 drives for boot/system operations
• Two 600 GB RAID 1 drives for Viewpoint data storage
• Onboard connectivity to server management network
• Onboard or adapter connectivity to customer network
Each Cabinet VMS consists of:
•
•
•
•
•
•
•
Extended Channel Solution
(ECS) Server
CMIC VM
Intel SR1625 chassis
One Intel 2.4 GHz quad-core CPUs
12 GB memory using 4 GB DIMMs
Two 300 GB RAID 1 drives for boot/system operations
Onboard connectivity to server management network
Onboard or adapter connectivity to customer network
Dell R710 chassis, configured as dedicated server for interface between Teradata Database
and IBM (or compatible) mainframe:
• Single Intel 2.4 GHz quad-core CPU
• 24 GB memory (using 4 GB DIMMs)
• Host channel adapters -- maximum three FICON and/or ESCON adapters (can mix
types in same node)
• No disk array support
• No amps assigned
• Onboard connectivity to the server management network
• Optional network communication adapter
Teradata Managed Server
(TMS)
Optional Dell R710 servers used for solution offerings that are peripheral to Teradata
processing.
All Teradata managed servers have onboard connectivity to the server management
network. They are not connected to the BYNET network.
For information about TMS configurations, see the Teradata Managed Server Product and
Site Preparation Guide for Cabinet and Server, Model s 4X5, 4X7, and 6X7.
Service Workstation (SWS)
26
Teradata workstation dedicated to system servicing and maintenance. For systems that use
dedicated SWS hardware (rather than a VMS with an SWS virtual machine), the SWS
hardware can reside as a standalone server or in a TMS cabinet.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 2: System Components
Hardware Components
Component
Description
Switches
Processing/storage cabinet 1 contains the following switches:
• Redundant Dell 6248 48-port Gigabit Ethernet switches for the BYNET-over-Ethernet
network
• Redundant Dell 2824 24-port Gigabit Ethernet switches for the server management
network
Processing/storage cabinets 2+ contain the following switches:
• Redundant Dell 2824 24-port Gigabit Ethernet switches for the server management
network
AC Power Subsystem
Two AC boxes of the same type per cabinet. Available AC box types:
• 30 Amp, NEMA L6-30P dual-cord AC box
• 32 Amp, IEC single-phase dual-cord AC box
Adapters
(not shown in diagrams)
Disk storage:
• LSI 9200-8E dual 6Gbx4 SAS PCIe2 low profile
Data reduction:
• Exar DX1845 PCIe2 low profile
Host channel:
• BTI ESCON PESA4 PCIe full height
• BTI FICON PEFA PCIe full height
Communications:
• Intel PRO/1000 PF dual PCIe low profile
• Intel PRO/1000 PT quad PCIe low profile
• Intel X520-DA2 Intel X520-SR2 dual 10 Gb PCIe2 low profile dual 10 Gb PCIe2 low
profile
Cable Management
Cabinets pre-wired for four cliques, with cable harnesses provided for power and server
management. For early installations, point-to-point storage and BYNET cables are
available.
Openings in cabinet sides near the rear of the rack to accommodate inter-rack cabling.
KVM Console
The KVM resides in the first processing/storage cabinet, and has VGA and USB connections
to the SWS server or VMS.
Teradata Data Warehouse Appliance 2690 Implementation Guide
27
Chapter 2: System Components
Hardware Components
System Scalability
The scalability of Teradata Data Warehouse Appliance 2690 system is dependent on the
BYNET network configuration of the system:
•
A system using Dell 6248 1Gb Ethernet switches in the first processing/storage cabinet for
BYNET-over-Ethernet network can scale to 46 nodes.
•
A system using BYA32S V4 switches in the first processing/storage cabinet for BYNET V4
network can scale to 32 nodes.
•
A system using BYNET V4 cabinets for BYNET V4 network can scale to 1,024 nodes
(theoretical maximum of 4,096 nodes).
Note: Systems with channel servers use a portion of the BYNET ports that are necessary for
communication between nodes, which limits the system to less than the maximum nodes.
Reference Information
Information on...
Is available in...
system cabinet configurations
“Example Cabinet Configurations” on page 21.
Customer Network and Mainframe Connection
Teradata Data Warehouse Appliance 2690 systems can attach to other operational computer
systems on a customer network through local area network (LAN) or mainframe connections.
Customer Network Attachment
Teradata Data Warehouse Appliance 2690 systems can communicate with intelligent
workstations and other computers and devices in a customer network through a LAN
connection. Gigabit Ethernet adapters in channel servers or ECS servers provide the necessary
ports for connecting to the customer LAN.
Mainframe (Channel) Attachment
The Teradata Channel Interface enables the Teradata Data Warehouse Appliance 2690 to
communicate with an IBM or IBM-compatible mainframe. FICON and ESCON channel
adapters in channel servers or ECS servers provide the ability for these systems to attach
directly to a mainframe computer.
Reference Information
28
Information on...
Is available in...
network or channel attachments
“Client Communication with Teradata Database,”
in Introduction to Teradata
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 2: System Components
Hardware Components
Hardware Data Protection
Teradata Data Warehouse Appliance 2690 uses RAID1 technology to protect against disk
failure and cliques to protect against node failure.
RAID1 Technology
Teradata Data Warehouse Appliance 2690 platforms use redundant array of independent disks
(RAID1) technology to provide data protection at the disk level. RAID1 is a disk-mirroring
technique. Each physical disk is mirrored elsewhere in the array. In the event of a disk failure,
Teradata operations continue uninterrupted. Performance may be reduced until the disk is
replaced and the mirror rebuilt.
Cliques
A clique is a collection of nodes with shared access to the same disk array. Teradata Data
Warehouse Appliance 2690 nodes and disk arrays are interconnected into a clique
configuration for fault tolerance. The only supported clique configuration for the Teradata
Data Warehouse Appliance 2690 is two database nodes to one disk array (with two drive
enclosures).
Dual 6 Gbx4 SAS HBA
Node 1
Node 2
1
1
HBA Ports 0-1
12
1 2
A
B
E
E
Tray 1
(24 disks)
1
2
E
1
2
E
Tray 2
(24 disks)
ARRAY_0123
Teradata Data Warehouse Appliance 2690 Implementation Guide
29
Chapter 2: System Components
Teradata Database Software Components
If a node fails, its tasks automatically move to the other node in the clique, which has direct
access to the storage for the failed node. The system continues running minus the failed node.
If a node fails and then resets:
1
Teradata Database restarts across all nodes.
2
When the database recovers, the BYNET redistributes the vprocs of the node to the other
nodes in the clique.
3
Processing continues while the failed node is repaired.
Reference Information
Information on...
Is available in...
virtual processors (vprocs)
“Teradata Database Hardware and Software Architecture,” in
Introduction to Teradata
Teradata Database Software Components
Teradata Database software is installed on all Teradata Data Warehouse Appliance 2690
processing nodes. There are three main database software components: the operating system,
parallel database extensions, and Teradata Database.
Parallel Database Extensions (PDE)
PDE is a software interface layer that sits on top of the operating system. PDE provides the
Teradata Database with the ability to:
•
Run the Teradata Database in a parallel environment
•
Execute vprocs
•
Apply a flexible priority scheduler to Teradata Database sessions
•
Debug the OS kernel and the Teradata Database using resident debugging facilities
PDE
OS
1193A001
30
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 2: System Components
Teradata Database Software Components
Teradata Database Software
The Teradata Database software is a trusted parallel application (TPA). There are four
components of the Teradata Database software—parsing engine (PE), access module
processor (AMP), channel driver software, and Teradata gateway software.
TPA: Teradata Database
PDE
1193A002
Parsing Engine (PE)
A PE is a virtual processor (vproc). The Teradata Data Warehouse Appliance 2690 is equipped
with 2 PEs per node. PEs are responsible for:
•
Managing individual sessions (up to 120 sessions per PE)
•
Parsing SQL requests
•
Building query plans with the parallel-aware, cost-based, intelligent optimizer
•
Dispatching the optimized query plan to the AMPs
•
Input conversion (ASCII, EBCDIC)
•
Sending the answer set back to the requesting client
Teradata Data Warehouse Appliance 2690 Implementation Guide
31
Chapter 2: System Components
Teradata Database Software Components
SQL Request
Answer Set Response
Parsing Engine (PE)
Session Control
Parsing
System Configuration
Optimizing
Data Demographics
Dispatching
BYNET
AMP
AMP
AMP
AMP
Storage
Storage
Storage
Storage
1193A003
Access Module Processor (AMP)
AMPs are vprocs that each control a portion of the data on the system. AMPs are responsible
for:
•
Accessing data on their associated storage
•
Lock management
•
Sorting rows and aggregating columns
•
Join processing
•
Output conversion and formatting (ASCII, EBCDIC)
•
Creating answer sets for clients
•
Disk space management and accounting
•
Executing special utilities
•
Recovery processing after database restarts
The Teradata Data Warehouse Appliance 2690 system is configured to have the number of
AMPs equal to the number of physical disks, that is, 24 AMPs per node=24 disk drives per
node.
32
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 2: System Components
Teradata Database Software Components
SQL Request
Answer Set Response
Parsing Engine (PE)
BYNET
AMP
AMP
AMP
AMP
Storage
Storage
Storage
Storage
1193A004
When data is loaded, inserted, and updated, the AMP:
1
Receives incoming data from the PE.
2
Formats rows and distributes them within its storage.
When data is accessed, the AMP retrieves the rows requested by the PE:
1
The database management subsystem receives the steps from the Dispatcher over the
BYNET.
2
The database management subsystem processes the steps. The subsystem on the AMP can:
3
•
Lock databases and tables
•
Create, modify, or delete definitions of tables
•
Join tables
•
Insert, delete, or modify rows within tables
•
Sort, aggregate, or format data
•
Retrieve rows from tables
The management subsystem returns responses over the BYNET to the Dispatcher.
Channel Driver Software
Channel driver software enables communication between a mainframe application and the
Teradata Database. The communication path for a channel-connected host is from the
channel-attached client, to the host channel adapter in the node, to the channel driver
software, to the PE.
Teradata Data Warehouse Appliance 2690 Implementation Guide
33
Chapter 2: System Components
Teradata Database Software Components
Mainframe
NODE
Host Channel
Adapter
(Hardware)
Channel
Driver
(Software)
PE
PE
PE
PE
Host Group
1193A005
Teradata Gateway Software
The Teradata gateway software enables communication between applications running on
network-attached clients and the Teradata Database. The communication path for networkattached clients is from the network attached client, to the network card in the node, to the
Teradata gateway software, to the PE.
Network Client
NODE
Network LAN
Adapter
(Hardware)
Gateway
(Software)
PE
PE
PE
PE
Host Group
1193A006
34
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 3
Setting Up System Management
Teradata Server Management Client (SMClient) is the principal management tool for the
Teradata Data Warehouse Appliance 2690. SMClient is available through Server Management
Web Services (SMWeb).
The tasks shown in this chapter are required for all Teradata Data Warehouse Appliance 2690
implementations. Perform all tasks and procedures completely and in the order presented.
Assumptions
•
Installation of the Teradata Data Warehouse Appliance 2690 is complete.
•
The CMIC is a virtual machine within the VMS.
•
SMWeb is version 9.0 or higher.
SMWeb Overview
Server Management Web Services (SMWeb) is used by Teradata Customer Service and site
administrative personnel to support the Teradata Data Warehouse Appliance 2690.
The main SMWeb Home page contains links to all SMWeb web applications and web pages. In
this chapter, “SMWeb Home page” is used to denote the web page of the SOV CMIC.
Teradata Data Warehouse Appliance 2690 Implementation Guide
35
Chapter 3: Setting Up System Management
SMWeb Overview
Note: One CMIC in a system is designated as the SOV CMIC. When you use a browser to
connect to the SMWeb Home page of an SOV CMIC, all links on the Home page are active.
The following figure provides a conceptual overview of the network connections for an SOV
CMIC.
Workstations
Cabinet 1
Cabinet 2
SOV
CMIC
Non-SOV
CMIC
Corporate LAN
Server Management LAN
SWS
SM_0019
Access to the SMWeb Home page of the SOV CMIC is through the corporate LAN or the
server management LAN.
•
The workstations you plan to use to manage your system must be connected to the
corporate LAN, and the corporate LAN must be connected to the SOV CMIC. If you have
a firewall, ports 9980 and 9981 must be open so browsers can connect to the SMWeb
Home page and access the web applications and web pages.
•
The Service Workstation (SWS) and SOV CMIC are both virtual machines within the
VMS. Optionally, systems can have a dedicated external SWS, connected over the private
server management LAN. Teradata Services uses the SWS for service operations. The level
of service depends on the service agreement between you and Teradata.
Although you can use a browser to access the SMWeb Home page from any workstation that is
network-connected to the SOV CMIC, specific access privileges are required for each web
application or web page.
36
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Configuring a Workstation for Use with SMWeb
Configuring a Workstation for Use with SMWeb
The following set-up procedures are required for running SMWeb applications. The
procedures have already been performed on the SWS at your site, but you must perform the
procedures on your corporate LAN-connected workstations that you plan to use to monitor
or manage a Teradata Data Warehouse Appliance 2690 system.
The minimum hardware requirements on a workstation used to access applications from the
SMWeb Home page are:
•
1.4 MHz CPU or greater
•
512 MB RAM (Recommended: 1 GB or greater)
•
200 MB hard drive space (for software prerequisites and caching application files)
Setting Up an Internet Explorer Browser on a Windows Workstation
If a Windows workstation is used to connect to the SOV CMIC through the corporate LAN,
use the following procedure to configure the workstation’s Internet Explorer (IE) browser. IE
must be version 6.0 or later.
1
From IE, select Tools > Internet Options.
2
On the Internet Options dialog box, select the Security tab.
3
On the Security tab, set up the SOV CMIC as a trusted site.
a
Click Trusted Sites, then click Sites.
b
At Add this web site to the zone, enter the CMIC identifier, and then click Add.
Note: The CMIC identifier is the host name and port number, or IP address and port
number, used to access the SMWeb Home page of the SOV CMIC. It is usually in the
following format:
http://<hostname or IP address of SOV-enabled CMIC>:9980/CWA/home.asp
The CMIC identifier is configured during installation. You must obtain the CMIC
identifier from your system administrator. If you have a firewall, ports 9980 and 9981
must be open.
c
4
On the Trusted sites dialog box, click OK.
On the Security tab, enable Javascript, then enable Active X controls:
a
Click Custom Level.
b
Verify that Active Scripting is enabled.
c
Under ActiveX controls and plug-ins, enable Run ActiveX controls and plug-ins and
Script ActiveX controls marked safe for scripting.
Note: Verify that site security policies allow you to run ActiveX controls and plugins. If
security policy does not allow this, some SMWeb features and functions are affected.
d
5
On the Security Settings dialog box, click OK.
On the Internet Options dialog box, click OK.
Teradata Data Warehouse Appliance 2690 Implementation Guide
37
Chapter 3: Setting Up System Management
Accessing the SMWeb Home Page
Setting Up a Firefox Browser
If Firefox is used to connect to the SOV CMIC through the corporate LAN, use the following
procedure to configure the workstation’s Firefox browser. Firefox must be version 2.0 or later.
1
From Firefox, select Tools > Options.
2
At Content, select Enable JavaScript.
3
Click OK.
Setting Up Software on a Workstation
Java Runtime Environment (32-bit J2SE JRE) 6.0 or greater is required for running SMClient
and the CLI utilities.
Use the following procedure to install this application on corporate LAN-connected
workstations that you plan to use to monitor or manage a Teradata Data Warehouse Appliance
2690 system.
Note: If Firefox is not configured to open .jnlp files with Java Web Start (javaws), when you
are prompted how to open this file, select javaws from the JRE bin directory.
1
Using a browser, connect to the following URL:
http://java.sun.com/javase/downloads/index.jsp.
2
Download the most current version of JRE 6.
3
Follow the directions on the screen. If you’re unsure, verify your installation with the
option on the following web page.
http://java.com/en/download/help/testvm.xml.
Accessing the SMWeb Home Page
All users can access the SMWeb Home page from workstations that are network-connected to
the SOV CMIC. If you access the Home page of a CMIC that is not an SOV CMIC, most web
applications and pages are unavailable.
Use the following procedures to access the SMWeb Home page of the SOV CMIC.
Note: The applications and web pages on the SMWeb Home page require specific access
privileges. See “Setting Up User Access to SMWeb Applications and Web Pages” on page 39.
Navigating to the SMWeb Home Page from the SOV CMIC
1
38
Open a browser from:
•
A workstation on the corporate LAN; the corporate LAN must be connected to the
SOV CMIC, and the workstation must be configured as described in “Configuring a
Workstation for Use with SMWeb” on page 37.
•
The SWS
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Setting Up User Access to SMWeb Applications and Web Pages
2
Type the following in the Address field of the browser, substituting the appropriate name
or IP address of the SOV CMIC:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
The SMWeb Home page opens.
Navigating to the SMWeb Home Page from a Non-SOV CMIC
If you access the Home page of a CMIC that is not an SOV CMIC, most web applications and
pages are unavailable. Use the following procedure to locate the SOV CMIC:
1
From the web page whose web applications and pages are unavailable, select Networks,
Devices, and CMICs.
Note: Only Service Users can access the Networks, Devices, and CMICs page.
2
In the Functionalities Hosted column, click sov. The SMWeb Home page appears.
Setting Up User Access to SMWeb Applications
and Web Pages
The applications and web pages on the SMWeb Home page require specific access privileges.
Access privileges are based on group memberships set up through the Users and Groups web
application.
Users, Enhanced Users, and Service Users are default SMWeb groups and cannot be deleted.
You can create additional groups that have access to specific SMClient web application
commands and server management CLI utilities.
After the Teradata Data Warehouse Appliance 2690 system is installed on site, you must
determine which users to add to which user groups, based on their use of the system.
User Group
Access
Users
Read-only access. They can view, but not change, information when using
SMClient and the server management CLI utilities. Recommended for
those who will monitor the system.
Enhanced Users
Same as Users, except they can run the SMClient Replace FRU command.
Recommended for those who will monitor the system and perform the
FRU replacement of customer-replaceable hardware (disk array storage
drives, disk array power supplies, node power supplies, and server
management power supplies)
Teradata Data Warehouse Appliance 2690 Implementation Guide
39
Chapter 3: Setting Up System Management
Setting Up User Access to SMWeb Applications and Web Pages
User Group
Access
Service Users
Access to all SMWeb applications and web pages, including all
SMClient commands and server management CLI utilities. One
Service User is required; a backup Service User is recommended.
The tasks that can be performed by non-Teradata Service Users are:
• Server Management Client and Server Management CLI Utilities: Monitor
the system and perform tasks related to the FRU replacement of
customer-replaceable hardware (disk array storage drives, disk array
power supplies, node power supplies, and server management power
supplies); power the system off/on; gather information for attachment
to incidents.
• Users and Groups: Add users to the pre-defined groups (Users,
Enhanced Users, or Service Users) or to user-defined groups based on
the tasks they will perform.
• Save and Restore: View alert logs and download files used to configure
SNMP trap receivers.
• Network, Devices, and CMICs: Navigate from a non-SOV CMIC to the
SOV CMIC.
• TVI Connection: Gather information for attachment to incidents.
<User-Defined
Group>
Access to specific SMClient commands and server management CLI
utilities.
Does not include access to all SMClient commands or server management
CLI utilities.
For more information about defining user groups whose members have
access to specific SMClient commands, see Users and Groups online help.
Members of each group have a specific login and password that are used when accessing
applications and web pages on the SMWeb Home page. For more information about users
and groups, see Users and Groups online help.
Adding a User, Enhanced User, or Service User
A Service User must use the following procedure to add users to the appropriate user groups
on the SOV CMIC. User names and passwords are stored on the SOV CMIC and do not
correspond to network user names and passwords on site.
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select Users and Groups.
Note: If Java Web Start has not yet been installed on the workstation, you will be
prompted to install it the first time you use either Users and Groups or SMClient. Follow
the prompts to install Java Web Start.
3
40
Log in as a Service User.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Setting Up Server Management Command Line Interface Utilities
4
Select the Users tab of the Users and Groups window.
5
Click New User to display the New User dialog box.
6
At Username, type the name the new user will use to access the system.
7
At Password, type the new user’s password. Retype the password at Confirm Password.
Passwords must be between six and 32 characters, and must contain at least one letter and
one number.
8
At Member Of, select the groups to which this user belongs. To add the user to only the
Users group, do not select any groups.
9
Click Save.
10 Repeat this procedure for each user you want to add to each user group.
Setting Up Server Management Command Line
Interface Utilities
The following set-up procedures are required for running the server management CLI utilities
remotely from a workstation. You must perform the procedures on each corporate
LAN-connected workstation that you plan to use to monitor or manage a Teradata Data
Warehouse Appliance 2690 system. After the utilities have been downloaded and set up, they
can be run from the command line on the workstation.
Java 1.6 is required to run the CLIs.
Setting Up SMWeb CLI Utilities on a Windows Workstation
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Click Command Line Interface for Windows Clients.
3
When prompted, click Save to save the zip file to a Windows workstation.
4
Navigate to \Program Files\teradata\sm, and click Save.
Create the directory if it doesn’t exist.
5
In an Explorer window, navigate to the saved zip file.
6
Extract the zip file to the new sm directory.
Note: As a default, the zip file wants to extract to a new directory under the sm
subdirectory with the IP address. Change that in the extraction program. If you don’t,
you’ll have to move the two new directories up to the sm directory.
7
Open a command window and navigate to the sm directory.
8
Under the sm directory, change to the new WinCLIs directory.
9
Run setup.
Teradata Data Warehouse Appliance 2690 Implementation Guide
41
Chapter 3: Setting Up System Management
Setting Up an Alert Subscription
10 When prompted, enter your SMClient login.
11 When prompted, enter your SMClient password.
12 When prompted, enter a pass phrase to encrypt the password file.
The pass phrase must be at least six characters long.
13 When the prompt returns, enter setup -test to test the connection.
Setting Up SMWeb CLI Utilities on a Linux Workstation
1
Display the SMWeb Main page.
2
Click Command Line Interface for Linux Clients
3
When prompted, click Save to save the zip file to your local system.
4
Navigate to /opt/teradata/sm, and click Save.
Create the directory if it doesn’t exist.
5
In a shell window, navigate to the saved zip file.
6
Extract the zip file using the -a option: unzip -a filename.zip
The Unzip program creates a new subdirectory called linuxCLIs. It then extracts the files
into that directory.
7
In the linuxCLIs directory, run cdmod +x * to make the files executable.
8
In the linuxCLIs directory, run ./setup.
9
When prompted, enter your SMClient login.
10 When prompted, enter your SMClient password.
11 When prompted, enter a pass phrase to encrypt the password file.
The pass phrase must be at least six characters long.
12 When the prompt returns, open a new shell and run setup -test to test the connection.
Note: If you move the CLI utility files, run setup again from the new directory.
Setting Up an Alert Subscription
Although the SMClient Alert Viewer is the primary method for monitoring the health of the
system (see “Monitoring System Health with SMClient” on page 55), you can also configure
SNMP traps. The traps send alert information to an SNMP trap receiver in an Enterprise
Management System (EMS).
The following procedures describe how to set up an alert subscription for Degraded, Critical,
and Fatal alerts.
About SNMP Trap Configuration
Configuring SNMP traps requires the following:
•
42
The corporate LAN must be cabled to the SOV CMIC.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Setting Up an Alert Subscription
•
The alert subscription must be configured to send the SNMP traps to the SNMP trap
receiver/server on the corporate LAN.
•
The SNMP port (UDP 162) must be allowed through the corporate firewall.
•
The user must understand SNMP traps.
•
If the SNMP trap is to be used in/with an EMS, the user must have experience with the
EMS software they plan to integrate with.
Creating an Alert Subscription for SNMP Traps
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select Server Management Client.
Note: If Java Web Start has not yet been installed on the workstation, you are prompted to
install it the first time you use either Users and Groups or SMClient. Follow the prompts to
install Java Web Start.
3
Log in as a Service User.
4
Select Tools > Alert Subscription.
5
On the Alert Subscription Manager dialog box, select New.
6
On the Alert Subscription dialog box, do the following to set up an alert subscription that
sends Degraded (severity level 4), Critical (severity level 5), and Fatal (severity level 6)
alerts to the SNMP trap receiver:
a
In Name, type a name for the alert subscription. For example: SendSNMPTraps.
b
Select the Match Criteria.
c
Set the corresponding operator to >=.
d
Set the corresponding value to 4.
e
Select Send SNMP Trap.
f
In Host IP Address, type the address of a server on the corporate LAN that is running
an SNMP trap receiver. This should be the server running the EMS software.
g
If applicable, in Community String, change the password that the SNMP trap receiver
has agreed to accept for incoming traps.
Note: The user administering the EMS must know when or if the password should be
changed.
h
Click Ok.
i
On the Alert Subscription Manager dialog box, click Close.
Teradata Data Warehouse Appliance 2690 Implementation Guide
43
Chapter 3: Setting Up System Management
Setting Up an Alert Subscription
Retrieving the SNMP Trap Definition (MIB File)
Users might need the information in the SMAlerting MIB.txt file to configure the SNMP trap
receiver or EMS. Use the following procedure to retrieve the SMAlerting MIB.txt file from
SMWeb.
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select Save and Restore.
3
Log in as a Service User.
4
In the SMA section of the web page, find the SMAlertingMIB.txt row, then move the cursor
to the Download link in that row, and right click.
5
Click Save Target As.
6
On the Save As dialog box, select a location.
SNMP Trap Definitions in the SMAlertingMIB.txt File
The SMAlerting MIB.txt file defines the alert content reported in the SNMP trap. The content
includes, for example, the severity level and domain of the alerts collected. If you want to limit
traps to specific alert content other than alert severity (see “About SNMP Trap Configuration”
on page 42, you can set match criteria that report only the information you want to see. The
trap content always contains all the fields defined in the MIB. The match criteria control
which alerts are turned into traps.
The following table describes the alert definitions in the SMAlertingMIB.txt file. Most of the
definitions correspond to the alert properties in the alert Detail window.
44
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Setting Up an Alert Subscription
MIB Entry
Corresponding
Property in Alert
Detail Window
Definition
severity
Severity
Severity level of the alert:
• Unknown
• Information: Draws attention to an event that:
• changes some characteristic of the subsystem, but leaves all
aspects of its operation at the same level
Note: A subsystem is defined as a part of the system (software
and/or hardware) that can be logically grouped together to
support a function.
• signifies the restoration of a previously diminished subsystem
No further degradation is anticipated.
• Warning: Draws attention to a condition that, if not addressed,
could become a more serious problem. The subsystem is still fully
functional at the same level of performance and redundancy.
• Degraded: The subsystem is degraded; an event has left the
subsystem fully functional but at a lesser performance level or with a
reduced level of redundancy.
• Critical: A function critical to the subsystem has been lost; the event
is a certain forerunner to a more fatal event.
• Fatal: The event has caused the subsystem to fail, and all or part of
the system is down.
domain
Domain
The problem area, which is typically a short name for the agent
reporting the alert. The following are examples of possible domains:
• Alerts reported by server management, including Node, CMIC,
ChassisAgent, CMICCore, BYNET, BYNETDP, ChassisMonitor,
UPS_PWDEB, FCSW_SB, FCSW_Brocade, ESW_Dell, ESW_SMC, and
Disk_Array alerts
• BYNETDriver: Alerts detected for BYNET driver events.
• CheckBatteries: Alerts reported by the CheckBatteries utility.
• Disk_Array-MEL: Alerts detected for MEL.
• FruReplace: Alerts generated while running FRU Replace.
• Linux domains: Alerts reported for Linux node software, including
Teradata for database related alerts.
• LSI-MEGARAID-STORAGE-MANAGER: Alerts for RAID Storage
Managers that logs disk status.
• SM_User: User or customer generated alerts.
• TAS: Alerts reported by TAS.
managedElementAlias
Alias
The default Alias of the component. If a user-defined Alias exists, it
displays instead of the default Alias.
description
Description
Message describing what occurred.
details
Details
Message listing several properties, some of which are unique to the alert
rule (for example, the event message that triggered the alert); also
includes binary data.
Teradata Data Warehouse Appliance 2690 Implementation Guide
45
Chapter 3: Setting Up System Management
Setting Up an Alert Subscription
MIB Entry
Corresponding
Property in Alert
Detail Window
Definition
ID
GUID
A unique Alert ID assigned to the alert.
managedElement
Component ID
The component associated with the alert.
messageID
Message ID
An alert name or message key or number unique within the Domain for
a specific type of alert.
reporterType
Reporter Type
MPP_Alert indicates this is an alert condition.
sequence
Sequence
Sequence and collective in which the alert was logged.
requestID
Request ID
Groups a sequence of alerts, such as command results
subType
SubType
An optional alert type; depends on the ReporterType or the type of
managed object. It identifies key alerts as AlertGroup or ProbableCause.
Heartbeat identifies issues or a restore of the node to the CMIC Event
path.
timeStamp
Time
The date and time that the alert was detected.
systemID
System ID
ID representing the system where the alert originated.
collectiveID
Collective ID
ID representing the collective where the alert originated.
cabinetID
Cabinet ID
ID representing the cabinet where the alert originated.
chassisID
Chassis ID
ID representing the chassis where the alert originated.
objectClass
ObjectClass
Object class name of the component (usually the first part of the
component ID).
timeReceived
TimeReceived
The time the CMIC recorded the alert.
status
Status
The status of the alert:
• Active: An alert that may represent:
• A serious condition in the system that requires action to
resolve the problem
• A temporary condition in the system that will resolve itself.
• Information about a component in the system.
• Auto Solved: An alert that has been automatically resolved within
the system. The Tree View and Status Window show that the
operational state of the component is OK.
• Cleared: The alert has been resolved by taking action to fix the
problem. This status can only be set manually using the Alert
Viewer.
46
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
MIB Entry
Corresponding
Property in Alert
Detail Window
Definition
tviDisposition
TVI_Disposition
The TVI disposition status. Options are:
• None: No disposition decided.
• Ignore_Maintenance: Maintenance window was open when this alert
occurred.
• Escalate_Requested: The reporter of the alert has requested TVI to
escalate, but TAS has not yet done so.
• Ignored: Not escalated by TVI because it is not on the Escalate list or
it has been specifically excluded.
• Abeyed: Not escalated by TVI because a previous similar alert was
escalated and subsequent escalation is suppressed for a period of
time. In TVI unconnected mode, an alert with a severity of less than
degraded is abeyed.
• Escalated: TVI has placed this alert in the TAS outbox or it has been
delivered to the SWS for upload to the TVI back end.
subsystem
Subsystem
The subsystem where the alert originated.
repeatCount
Repeat Count
The number of times this alert has repeated since the value in Repeat
Start Time.
isInGroup
---
Numbers of alert groups that were associated with this alert
repeatStartTime
Repeat Start Time The time the repeat was first seen within a day
trackingID
Tracking ID
Used for AutoSolving and repeat tracking.
knowledgeID
Knowledge ID
The knowledge file, version, and rule name that triggered this alert.
autoSolvable
AutoSolvable
Indicates whether the alert is auto-solvable.
smaAlertTrap
---
The trap name as defined on the Delivery tab of the Alert Subscription
dialog box.
Working with SMClient Default Views
You must set up SMClient default views to monitor the Teradata Data Warehouse Appliance
2690 system.
Setting Up SMClient Default Views
The SMClient Tree View, Alert Viewer, and Status Window provide a basic overview of system
operation. These windows represent the recommended default view for an administrator,
user, enhanced user, or service user who is monitoring the system.
Note: The SMClient tasks and procedures in this section focus on the recommended default
view.
Teradata Data Warehouse Appliance 2690 Implementation Guide
47
Chapter 3: Setting Up System Management
Working with SMClient Default Views
SMClient stores the view preferences of each user. Each user must do the following to set up
the default SMClient view that will appear at log on.
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select Server Management Client.
Note: If Java Web Start has not yet been installed on the workstation, you will be
prompted to install it the first time you use either Users and Groups or SMClient. Follow
the prompts to install Java Web Start.
3
Log in.
4
On the Menu bar at the top of the screen, select Window. The Window menu appears.
5
In the Window menu, if the following windows do not have a check mark beside them,
click the name of the window:
•
Tree View
•
Alert Viewer
•
Status Window
The Tree View, Alert Viewer, and Status windows are displayed in the SMClient
application. When you log off, SMClient saves the windows you checked and restores them
the next time you open the SMClient application. “SMClient Default Views Used to
Monitor the System” on page 49 describes the features and purpose of each window.
Note: You can concentrate on a single window at any time by deselecting the other
windows in the Window menu. You can also click Window > Tile to evenly distribute the
windows to the right of the Tree View.
48
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
SMClient Default Views Used to Monitor the System
Tree View
The Tree View displays the operational states of chassis and chassis components monitored by
server management. The primary operational states are displayed, in text, to the right of each
component. Other text may follow the primary operational state and provide additional
information. For a description of the operational states, see “Operational States in the Tree
View and Status Window” on page 50.
The following figure shows the SMClient Tree View for a Teradata Data Warehouse Appliance
2690.
Status Window
The Status window displays the operational states of chassis components monitored by server
management, organized by collective, in the Teradata Data Warehouse Appliance 2690. When
the operational state of a component changes, the associated color icon is automatically
updated in the Status window. For a description of the operational states, see “Operational
States in the Tree View and Status Window” on page 50.
Teradata Data Warehouse Appliance 2690 Implementation Guide
49
Chapter 3: Setting Up System Management
Working with SMClient Default Views
The Status window shows:
•
Each collective in the system, arranged by collective number (lowest-numbered collective
to highest-numbered collective).
•
One cabinet entry for each collective.
•
For each cabinet entry, icons representing the operational state of each chassis in the
cabinet, including the server management chassis (CMIC).
To find a chassis in the Tree View, click the chassis icon in the Status window. The chassis
location is highlighted in the Tree View.
Operational States in the Tree View and Status Window
The operational state of a component represents the overall health of a component.
Operational states are based on system events. An event indicates a change in the system.
Events that are serious enough to affect the ongoing operation of the system generate alerts
that may require action.
50
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
The following table describes the operational states displayed in the SMClient Tree View and
Status Window.
Tree View Text
Status Window
Icons
Primary Operational State Description
OK
No action required; the component is operating normally.
Warning
The condition should be monitored; the component or
subsystem is reporting a condition that does not threaten system
operation, but if not remedied could worsen over time.
Critical
Immediate action should be taken; the component or subsystem
will not continue to operate in this state
Note: Critical conditions are often handled internally by
components or subsystems, causing them to shut down.
Fatal
Immediate action must be taken to return the system to its
normal operating state; the component or subsystem has failed.
Unknown
The component severity level is unknown.
Missing
The component is expected to be present in the system, but is
either not present (MISSING) or has not been detected.
Powered Off
The component is powered off.
Alert Viewer
Alerts represent serious conditions in the system and may require action to resolve the
problem. Alerts are often triggered by events. By default, the Alert Viewer displays active alerts
in time sequence, with the most recent alert displayed at the top.
Note: If a key icon appears in the Alias column of the alert, the alert is a key alert. A key alert
identifies an alert as part of an AlertGroup (one of several alerts associated with a particular
problem or component) or an alert with a ProbableCause.
Teradata Data Warehouse Appliance 2690 Implementation Guide
51
Chapter 3: Setting Up System Management
Working with SMClient Default Views
The Alert Viewer automatically displays updates as alerts are added, cleared, or autosolved.
For example, if an event with an operational state of OK is available (the component is now
operating normally, as shown by its operational state in the Tree View or Status window), the
status of previously reported alerts for the component is changed to AutoSolved, indicating
that the problem condition is resolved.
Alert Properties and Alert Severities
In the Alert Viewer, alerts are listed in rows. The columns in the Alert Viewer show alert
properties, which include such information as the component affected (Alias column), the
severity of the alert (Severity column), and the time the alert occurred (Time column).
If an alert property you are looking for is not displayed, right-click any column heading in the
Alert Viewer, and select the alert property you want to display. For a complete list of alert
properties, see “SNMP Trap Definitions in the SMAlertingMIB.txt File” on page 44.
The following table describes only the alert properties that provide:
•
Information needed to determine whether you can fix the problem
•
Information that you can attach if you need to create an incident through
Teradata @ Your Service
Alert
Property
Description
Alias
Component name; the unique identifier for the component.
The component name can be its default alias or a user-defined alias.
For example, for Node Power Supply 1 in System 1, Collective 200, Cabinet 1, Node 8, the
default alias for the node power supply is:
PS.1.200.1.8.1
Note: If a user-defined alias is displayed, it may be easier to identify the component if
you change the display to the default alias. See the topic “Component Names” in
SMClient online help or Chapter 2 in the Server Management Web Services User Guide.
Status
• Active: An alert that may represent:
• A serious condition in the system that requires action to resolve the problem
• A temporary condition in the system that will resolve itself.
• Information about a component in the system.
• Auto Solved: An alert that has been automatically resolved within the system. The
Tree View and Status Window show that the operational state of the component is
OK.
• Cleared: The alert has been resolved by taking action to fix the problem. This status
can only be set manually using the Alert Viewer.
Time
52
Date and time the alert was detected
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Alert
Property
Severity
Description
Impact of the alert at the system level (how urgent it is to correct the problem
condition)
Severity levels:
• Unknown
• Information: Draws attention to an event that:
• changes some characteristic of the subsystem, but leaves all aspects of its
operation at the same level
Note: A subsystem is defined as a part of the system (software and/or hardware)
that can be logically grouped together to support a function.
• signifies the restoration of a previously diminished subsystem
No further degradation is anticipated.
• Warning: Draws attention to a condition that, if not addressed, could become a
more serious problem. The subsystem is still fully functional at the same level of
performance and redundancy.
• Degraded: The subsystem is degraded; an event has left the subsystem fully
functional but at a lesser performance level or with a reduced level of redundancy.
• Critical: A function critical to the subsystem has been lost; the event is a certain
forerunner to a more fatal event.
• Fatal: The event has caused the subsystem to fail, and all or part of the system is
down.
Description
Text message giving a brief synopsis of the problem
Domain
Subsystem impacted by the alert; the Domain identifies the type of alert.
Alerts (problem conditions) reflect known problem scenarios, such as configuration
issues or potential hardware or software failures. Some typical faults are as follows:
• Platform hardware faults:
• Disk array
• Node (SMP)
• CMIC
• Ethernet switch
• Software faults:
• Teradata Database
• Linux node (SMP) operating system/software
• Windows CMIC operating systems/software
Alert Details
The Detail window can be used to understand the meaning of an alert, the actions to take to
resolve a problem, and to report details when opening an incident through Teradata @ Your
Service. To display the Detail window for a specific alert, double-click the alert in the Alert
Viewer. For descriptions of the alert properties, see “Alert Properties and Alert Severities” on
page 52.
Teradata Data Warehouse Appliance 2690 Implementation Guide
53
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Event Viewer
The Event Viewer (Event Mgmt > View Events) is a supporting tool that can provide
information about the events occurring around the time of an alert or operational state
change. You can view events for the entire system, or by collective, cabinet, or chassis.
Events are displayed in time sequence, with the most recent event displayed first. Entries
include hardware events reported by server management, software events from the node error
54
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Monitoring System Health with SMClient
logs, operational state changes, and command status events. The Event Viewer is used
primarily to analyze problems that result in the generation of an alert.
Events in the Event Viewer do not require you to take action. The Event Viewer Severity
column indicates the seriousness of an event that occurs for a particular component. You can
double-click an event to display the Event Details window, which provides additional
information about the selected event.
Monitoring System Health with SMClient
Use the Server Management Client Alert Viewer to monitor alerts at regular intervals, or when
you suspect a problem in the system.
Monitoring the Alert Viewer for System Alerts
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select Server Management Client.
3
Log in as a Service User.
The SMClient application opens with the Tree View and Alert Viewer displayed by default.
4
5
Make sure that Alert Viewer is displaying the following column headings (alert
properties):
•
Alias
•
Status
•
Time
•
Severity
•
Description (optional)
•
Domain
If these column headings (alert properties) are not displayed, do the following to display
them:
a
In Alert Viewer, right-click any column heading.
b
Select a missing alert property from the list.
c
Repeat step a and step b for each property you want to add to the Alert Viewer.
Note: To see more properties in the Alert Viewer, you can extract it from the right pane.
To extract the Alert Viewer, select the Alert Viewer title bar, then select Window > Extract
and resize the Alert Viewer as needed.
6
By default, Alert Viewer entries are arranged by date and time. Scroll through the alerts
shown in the Alert Viewer periodically, especially if the system has run unattended for a
period of time such as overnight or over a holiday or weekend, and review the alerts
Teradata Data Warehouse Appliance 2690 Implementation Guide
55
Chapter 3: Setting Up System Management
Monitoring System Health with SMClient
recorded by the system since your last review. Schedule your review for the same time each
day, for example upon arrival each workday morning so as not to miss a review.
Note: You can also set up an alert subscription to send SNMP traps to an SNMP receiver
through your EMS. See “Setting Up an Alert Subscription” on page 42.
7
When you review the alerts in Alert Viewer, look in the Severity column for alerts with a
severity level of Degraded, Critical, or Fatal.
•
If there are no alerts with those severity levels, no action is required.
•
If there are alerts with those severity levels, but the Status column has a value of Auto
Solved, no action is required for system components.
Note: Further action may be needed for some alerts even if the Status is Auto Solved.
For example, an automatic database restart may be associated with a down virtual
processor (vproc). You can use Vprocmanager to verify that all vprocs are operational
after a database restart, as shown in “Troubleshooting Database Restarts” on page 250.
•
If there are alerts with those severity levels, and the Status column has a value of Active,
see “Determining When to Take Action to Fix a Problem” on page 56.
Reference Information
Information on...
Is available in...
SMWeb alert functions
Server Management Web Services User Guide
Determining When to Take Action to Fix a Problem
For alerts with a severity level of Degraded, Critical, or Fatal in the Alert Viewer that are not
Auto Solved, determine whether you can fix the problem.
56
1
In Alert Viewer, select an alert with a severity level of Degraded, Critical, or Fatal.
2
In Alert Viewer, select Functions > View Details, or double-click the alert.
3
In the Detail window, review the Description, Meaning, and Recommended Action.
•
If the component is a disk array storage drive, disk array power supply, or node power
supply, it is customer-replaceable. See “Working with Customer-Replaceable
Components” on page 57.
•
If the component is not customer-replaceable, you must open an incident with
Teradata @ Your Service to arrange for the part to be replaced. See “Opening an
Incident” on page 59.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Working with Customer-Replaceable Components
Working with Customer-Replaceable
Components
Preparing to Replace a Problem Component
Caution:
You should attempt to replace only the components that are customer replaceable.
1
Open a TVI maintenance window. See “Opening a Maintenance Window” on page 57.
2
Follow the procedures in Teradata Data Warehouse Appliance 2690 Platform Customer
Guide for Hardware Replacement to replace the failed component.
•
For a disk array storage drive, see Chapter 3.
•
For a disk array power supply see Chapter 4.
•
For a processing node or server management node power supply, see Chapter 5.
Note: Component replacement requires that you log in to SMClient as an Enhanced User
or Service User.
3
If replacing the component fixed the problem, and a maintenance window is open for the
component, close the maintenance window. See “Closing a Maintenance Window” on
page 58.
4
When the replacement is complete, see “Determining Whether Your Action Solved the
Problem” on page 58.
Opening a Maintenance Window
When performing system maintenance or replacing customer-replaceable components, open
a TVI maintenance window to temporarily stop alerts from being sent to Teradata Services.
The following procedure describes how to open a maintenance window when performing
system maintenance or replacing a component. For regular maintenance, scheduling a
maintenance window ahead of time is recommended. For more information, see SMClient
online help.
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select Server Management Client.
3
Log in as a Service User.
The SMClient application opens with the Tree View and Alert Viewer displayed by default.
4
In the SMClient Tree View, select the failed disk drive or power supply.
5
Select Functions > Maintenance Window. The quick-activation Maintenance Window dialog
box opens.
6
Set the Start Time and the Length of Maintenance (Hours). Time must be entered in the
format YYYY-MM-DD HH:MM:SS.
Teradata Data Warehouse Appliance 2690 Implementation Guide
57
Chapter 3: Setting Up System Management
Working with Customer-Replaceable Components
7
Click Activate.
8
If more time is needed to complete the procedure, extend the duration of the open
maintenance window by changing the number of hours in the Length of Maintenance
(Hours) field, then click Update.
9
Do not exit the quick-activation Maintenance Window at this time.
Closing a Maintenance Window
When servicing or replacement is complete, close the maintenance window to resume sending
alerts to Teradata Services.
1
In the quick-activation Maintenance Window, click Delete.
Determining Whether Your Action Solved the Problem
1
After replacing a disk array storage drive, disk array power supply, node power supply, or
server management power supply, open the Alert Viewer as described in “Monitoring
System Health with SMClient” on page 55.
2
Look for the alerts related to that component.
For disk array storage drives, disk array power supplies, node power supplies, or server
management (CMIC) power supplies, Auto Solved should appear in the Status column if
the replaced components go from a failure state to an OK state.
3
If the alerts are normal due to the replacement, no action is required. Faults that are
normal due to a replacement include:
•
FRU Replace session initiated
•
Power Supply Missing (if a power supply is being replaced)
•
FRU Replace session completed
If alert reporting continues after component replacement, opening an incident is required.
4
If the alerts are normal due to the replacement, clear the alert. In the Alert Viewer:
a
Select the alert.
b
Select Functions > Clear Alert(s), or right click the alert.
This changes the alert status to Cleared.
Reference Information
58
Information on...
Is available in...
SMClient alert functions and
maintenance window functions
Server Management Web Services User Guide
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Opening an Incident
Opening an Incident
When to Open an Incident
Note: This guide assumes the site has a maintenance agreement that does not include
automatic incident creation (AIC). If the site has a support agreement that includes AIC, you
do not need the procedures in this topic. You can advance to “Chapter 4 Setting Up Teradata
Clients” on page 63.
Open an incident using Teradata@Your Service when:
•
A component with an alert is not customer-replaceable and Degraded, Critical, or Fatal
appears in the Severity column of the Alert Viewer.
•
The Alert Viewer does not show a Status of AutoSolved for a replaced component.
Recommendation: Gather the supporting information and attach it to the incident. This may
save Teradata Customer Service time in diagnosing the problem.
Gathering Needed Supporting Information for an Incident
To gather supporting information for an incident:
1
Using a browser, connect to the SMWeb Home page by typing the following in the Address
field of the browser:
http://<hostname or IP address of SOV-enabled
CMIC>:9980/CWA/home.asp
2
Select TVI Connection.
3
Log in as a Service User.
The TVI Connection web page opens.
4
In the Outbox section, make the following selections:
a
Type: Alert
b
Time: From Now
c
Time: to <select the approximate time an alert identifying the
problem appeared in the Alert Viewer>
5
After the zip file is created, click the link to the zip file and save it to your workstation.
6
Open an incident and attach the saved zip file. See “Opening Incidents Through
Teradata @ Your Service” on page 59.
Opening Incidents Through Teradata @ Your Service
1
Access the Teradata @ Your Service website at:
https://tays.teradata.com.
2
Log into Teradata @ Your Service.
3
On the Teradata @ Your Service main page, select Service Requests, then select Create.
Teradata Data Warehouse Appliance 2690 Implementation Guide
59
Chapter 3: Setting Up System Management
Opening an Incident
4
5
On the Create Service Request - Step 1 of 5 page, do the following:
a
Select the site where the failure occurred.
b
From the drop-down list, select Hardware as the problem area.
c
Click Continue.
On the Create Service Request - Step 2 of 5 page, do the following:
a
Enter a brief problem description, verify the accuracy of your contact information, and
indicate the problem’s priority.
Note that required fields are indicated with a red asterisk.
b
Check the Leave this box checked for the submitter to be notified by email of updates to
this incident box.
This ensures that all follow-up emails regarding this incident will be sent to the address
entered in the Submitter Email Address field.
c
6
Click Continue.
On the Create Service Request - Step 3 of 5 page, do the following:
a
Specify the affected component.
b
Describe the problem as completely as possible.
c
Indicate whether a support person is already engaged.
d
Click Continue.
7
On the Create Service Request - Step 4 of 5 page, enter any additional information useful
for troubleshooting the problem, then click Continue.
8
On the Create Service Request - Step 5 of 5 page, do the following:
a
Verify the information is correct.
b
Add attachments, including the zip file you generated in “Gathering Needed
Supporting Information for an Incident” on page 59.
c
Click Create Service Request.
d
When the Create this service request? confirmation box appears, click Yes.
The Teradata@ Your Service main page appears. The newly created incident appears at the top
of the Incidents list. Teradata @ Your Service sends an email to the address entered in the
Submitter Email Address field confirming the creating of the incident.
Reference Information
60
Information on...
Is available in...
SMWeb alert functions
Server Management Web Services User Guide
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 3: Setting Up System Management
Checkpoint
Checkpoint
Before leaving Chapter 3: “Setting Up System Management,” make sure that:
√
Result
Reference
Your Internet browser is configured.
“Setting Up an Internet Explorer Browser
on a Windows Workstation” on page 37
Java Runtime Environment (32-bit J2SE
JRE) 6.0 or greater is installed on any
LAN-connected workstation that
monitors and manages the appliance.
“Setting Up Software on a Workstation”
on page 38
You can access the SMWeb home page of
“Navigating to the SMWeb Home Page
from the SOV CMIC” on page 38
the SOV CMIC.
SMWeb access privileges are set up.
“Setting Up SMWeb CLI Utilities on a
Windows Workstation” on page 41
The server management CLI utilities are
set up on each corporate LAN-connected
workstation used to monitor or manage
the 2690 system.
See either:
SNMP traps are configured (if you plan to use
them).
“About SNMP Trap Configuration” on
page 42
SMClient default views are set up to monitor
the system.
“Setting Up SMClient Default Views” on
page 47
You can use the Server Management Client
Alert Viewer to monitor alerts.
“Monitoring the Alert Viewer for System
Alerts” on page 55
• “Setting Up SMWeb CLI Utilities on a
Windows Workstation” on page 41
• “Setting Up SMWeb CLI Utilities on a
Linux Workstation” on page 42
If you do not have these results, return to the section in the Reference column and review that
procedure.
Teradata Data Warehouse Appliance 2690 Implementation Guide
61
Chapter 3: Setting Up System Management
Checkpoint
62
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 4
Setting Up Teradata Clients
This section covers the installation and configuration of a subset of Teradata Tools and
Utilities software on Windows clients, sufficient for initial implementation of a Teradata Data
Warehouse Appliance 2690 system.
Complete installation information for all supported client operating systems is available in the
Teradata Tools and Utilities Installation Guides, available from http://www.info.teradata.com.
Required Tasks
Perform all tasks and procedures completely and in the order presented.
About Client Software Installation
Most client application software is installed via SMS or from CD ROMs distributed with the
Teradata Tools and Utilities installation kit. The exceptions are:
•
Access dependent software, such as Microsoft .NET Framework. Links are provided to
manufacturer websites.
•
A few Teradata Tools and Utilities software products, such as OLE DB Provider for
Teradata, are only available for download from the Teradata Download Center at:
http://www.teradata.com/t/support-and-downloads/.
Some of the software requires configuration after installation. The topics beginning with
“Configuring Network Name Resolution” on page 69 show the configuration procedures
necessary for a basic installation of Teradata Data Warehouse Appliance 2690.
Supported Platforms
To see a list of the client platforms supported by Teradata Tools and Utilities 14.00:
1
Go to http://www.info.teradata.com.
2
Under the Online Publications heading, click General Search.
3
Type 3119 in the Publication Product ID box.
4
Under Sort By, select Date.
5
Click Search.
6
Open or download Teradata Tools and Utilities 14.00.00 Supported Platforms and Product
Versions. This list is in a spreadsheet format.
Teradata Data Warehouse Appliance 2690 Implementation Guide
63
Chapter 4: Setting Up Teradata Clients
Installation Guidelines
Installation Guidelines
Review the list of client software included with the Teradata Data Warehouse Appliance 2690
and the installation guidelines before beginning client software installation.
Standard Client Software Bundle
The installation kit includes the following bundled client software CDs that are required for
the implementing the Teradata Data Warehouse Appliance 2690. Verify that you have them all.
•
Teradata Utility Pack for Windows - Vol. 1 of 3
•
Database Management
•
Parallel Transporter for Windows - Vol. 1 of 3
•
Tape Storage Management Enablers Linux-MP-RAS-Windows
•
Preprocessors for Windows - Vol. 1 of 3
Note: Other CDs are included in the installation kit, but are not listed because they are not
used for the procedures in this book. For example, Volume 2 of 3 and Volume 3 of 3 CDs are
for non-Windows clients.
Note: Some of the programs found on the included CDs are not bundled with the system and
must be purchased separately to be available for use. Check your software license agreement.
If any CDs are missing, contact Teradata Customer Services at http://www.teradata.com.
Optional Client Software
Some available software options are not part of the installation kit. You may have one or more
additional software CDs if you purchased any of the following optional software:
•
Mainframe Connection
•
Teradata Warehouse Miner
User Documentation
Although multiple versions of Teradata Tools and Utilities software are compatible with
Teradata Database 14.0, this Guide is based on Teradata Tools and Utilities version 14.00.
User documentation for Teradata Tools and Utilities 14.00 products is available for download
from http://www.info.teradata.com.
Client Software Installation
The Teradata Tools and Utilities client software required to carry out the implementation
procedures in this book include some applications that are for installation on all clients, and
others that should be installed only on administrative clients.
Some applications may appear on more than one CD, but the following table lists each
package only one time, indicating that they only need to be installed once.
64
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Installation Guidelines
Software Supported on Teradata Data Warehouse Appliance 2690
Install on...
Teradata Utility Pack for Windows CD
Shared ICU Libraries for Teradata
All clients
Teradata GSS Client (Teradata Generic Security Services)
All clients
ODBC Driver for Teradata
All clients
CLIv2 (Teradata Call-Level Interface version 2)
All clients
Data Connector
All clients
.NET Data Provider for Teradata
All clients
BTEQ (Basic Teradata Query)
All clients
Named Pipes Access Module
Administrative clients
Teradata SQL Assistant
All clients
Teradata Administrator
Administrative clients
Parallel Transporter for Windows CD
Teradata Parallel Transporter (Teradata PT)
Administrative Clients
Teradata PT Export Operator
Administrative Clients
Teradata PT Load Operator
Administrative Clients
Teradata PT Update Operator
Administrative Clients
Database Management CD
Teradata Index Wizard
Administrative Clients
Teradata Statistics Wizard
Administrative Clients
Teradata Visual Explain
Administrative Clients
Note: Applications not shown in this list are not required for basic implementation of the
Teradata Data Warehouse Appliance 2690, for example:
•
Load/Unload for Windows
•
Meta Data Services
•
Preprocessors for Windows
•
Query Director Linux - Windows
•
Tape Storage Management Enablers
•
Teradata Appliance Backup Utility
Installation of these packages is optional. See Teradata Tools and Utilities Installation Guide for
Windows (or other operating system), available from http://www.info.teradata.com.
Teradata Data Warehouse Appliance 2690 Implementation Guide
65
Chapter 4: Setting Up Teradata Clients
Installing Microsoft .NET Framework
Installing Microsoft .NET Framework
Teradata SQL Assistant requires Microsoft .NET Framework, version 2.0 or later and the .NET
Data Provider for Teradata:
•
.NET Framework
Windows Vista and later Microsoft operating systems come with the .NET Framework
already installed. For client machines that do not have Microsoft .NET Framework,
download and install the latest version of any available updates from:
http://www.microsoft.com/downloads
•
.NET Data Provider for Teradata
.NET Data Provider is included on the Teradata Utility Pack CD, and is automatically
selected for installation whenever Teradata SQL Assistant is selected. You can also
download the .NET Data Provider for Teradata from the downloads page at:
http://www.teradata.com
Note: .NET Framework and .NET Data Provider for Teradata are required only for Teradata
SQL Assistant.
Installing Teradata Tools and Utilities
Teradata recommends that you first install Teradata Tools and Utilities on an administrative
client machine. Install all the applications listed in “Client Software Installation” on page 64.
1
Close all active Windows programs and, if possible, disable virus protection software.
Note: Some virus protection software can prevent successful installation of Teradata Tools
and Utilities applications.
2
Insert the Teradata Utility Pack for Windows CD into the CD drive.
3
In the Welcome to Teradata Tools and Utilities screen, click Install Product.
Note: If the Welcome screen does not appear shortly after the CD is inserted, use Windows
Explorer to locate the setup.bat file on the CD. Double-click on setup.bat to start the
installation process.
4
In the Choose Setup Language dialog, select a language, and click OK.
5
Read the information in the Welcome dialog, and click Next.
6
Read the information in the Software License Agreement dialog, and click Yes to agree.
7
In the Setup Type dialog, click Custom, then click Next.
8
Consult the table in “Client Software Installation” on page 64 to determine which Teradata
Tools and Utilities programs to install, based on whether the client machine will be used to
administer the Teradata Database system.
In the Select Components dialog, click to check the Teradata Tools and Utilities programs
to be installed from this CD. If the checked programs require other programs to be
installed from the CD, those programs will be checked automatically.
66
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Using the Latest Software Updates
Note: If you have already installed any Teradata Tools and Utilities programs on this
machine, some components may have already been installed. If a dialog asks about
reinstalling a component that is already installed, click Yes if the dialog offers to replace it
with a more recent version, otherwise click No.
9
In the Choose Destination Location dialog, Teradata recommends accepting the default
installation location by clicking Next.
Note: Write access to the destination folder, the Windows root folder, and the Windows
system folder is required to perform this installation.
10 In the Select Install Method dialog, accept the default selections, and click Next.
If an informational dialog regarding a product response file appears, click OK to dismiss it.
The files required for the installation are copied to the computer from the CD.
11 In the Setup Complete dialog, check the box to read the Teradata Tools and Utilities
Release Definition if you have not already done so, and click Finish.
The Release Definition provides an overview of the products and programs in Teradata
Tools and Utilities 14.00. It contains important information received late in the release,
which may not be included in other release documentation.
12 Click Exit in the Welcome to Teradata Tools and Utilities screen.
13 Repeat steps 2 through 12 for the remaining Teradata Tools and Utilities CDs listed in the
table in “Client Software Installation” on page 64.
Using the Latest Software Updates
After installing Teradata Tools and Utilities the delivered Teradata Tools and Utilities software
on a client, always download and install the latest software updates.
Downloading the Latest Updates
Download the most recent updates to Teradata Tools and Utilities from the Teradata @ Your
Service customer support website: https://tays.teradata.com.
1
Use the Client Patches link to get to the Teradata Software Server page.
2
On the Teradata Software Server page:
•
For Platform, choose Windows.
•
For Software Base, choose TTU14.00.
•
For Platform Base, choose i386.
3
Click Submit.
4
Select the patches for the Teradata Tools and Utilities programs installed in the previous
task. The following table lists the programs with their corresponding package names.
Teradata Data Warehouse Appliance 2690 Implementation Guide
67
Chapter 4: Setting Up Teradata Clients
Using the Latest Software Updates
Teradata Tools and Utilities Program
Package Name
Teradata Utility Pack for Windows
Shared ICU Libraries for Teradata
tdicu
Teradata GSS Client (Teradata Generic Security Services)
TeraGSS
ODBC Driver for Teradata
tdodbc
CLIv2 (Teradata Call-Level Interface version 2)
cliv2
Data Connector
piom
.NET Data Provider for Teradata
tdnetdp
Available from the Downloads page at http://www.teradata.com.
BTEQ (Basic Teradata Query)
bteq
Named Pipes Access Module
npaxsmod
Teradata SQL Assistant
sqla
Teradata Administrator
tdadmin
Parallel Transporter for Windows CD
Teradata Parallel Transporter (Teradata PT)
tbldd000
Teradata PT Export Operator
pexpd000
Teradata PT Load Operator
plodd000
Teradata PT Update Operator
pupdd000
Database Management CD
Teradata Index Wizard
tiwiz
Teradata Statistics Wizard
TSWiz
Teradata Visual Explain
vecomp
If more than one patch is listed for a program, download only the most recent patch.
Note: If there are dependencies (patches or programs required for installing the update)
indicated in the Dependency column for a patch, click the link to see the dependencies.
Check the Readme file for any additional dependencies and download the related patches.
68
5
At the bottom of the screen, for Download Type, click Windows, and for Download Readme
Files, click Yes.
6
Enter your User Name and E-Mail Address, then click Submit. It may take a few moments
for the website to assemble and display the download package.
7
Click Download.
8
In the File Download dialog, click Save to save the .zip file containing the patches to the
client machine. Remember the location where you saved the file.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Downloading the Windows Help Program
Installing the Latest Updates
1
Open the downloaded .zip file using one of the following methods:
•
Double-click the .zip file.
•
Right click on the .zip file and click Open.
•
Use a .zip file utility to extract the contents of the .zip file to a known location.
The .zip file contains a .zip or.exe file and a .txt file for every patch you specified.
2
For every patch:
a
Open the .txt file to read the Readme information that applies to that patch. Note and
follow any prerequisites to installing the patch.
b
Open the associated .zip or .exe file.
c
Double-click DISK1. This folder may be inside a DiskImages folder. If there is no DISK1
folder, go on to the next step.
d
Double-click setup.exe, and follow the installation instructions to install the patch.
Downloading the Windows Help Program
Some Teradata Tools and Utilities programs provide online help in Windows Help format.
The winhlp32.exe program, required to display the help, is included in Windows operating
systems prior to Windows Vista. For clients running Windows Vista or a later Microsoft
operating system, you must install winhelp32.exe.
To download and install the Windows Help Program:
1
Go to http://www.microsoft.com/downloads/
2
In the Search box, type: WinHlp32 Vista
3
On the search Results page, click WinHlp32.exe for Windows Vista.
Note: Windows Vista users must pass a short validation process before downloading the
file. After the validation, specific instructions are given for obtaining the download.
4
Follow the instructions to download and install WinHlp32.exe.
Configuring Network Name Resolution
When the Teradata Data Warehouse Appliance 2690 is installed, it is assigned a name by which
the system is known to the local area network. This name is sometimes referred to as the
tdpid. Teradata Tools and Utilities client applications require that certain entries exist in the
network DNS tables or in the hosts file on each client machine.
A network administrator should check whether the following aliases have been defined for the
network DNS or in the hosts file of every client machine.
Teradata Data Warehouse Appliance 2690 Implementation Guide
69
Chapter 4: Setting Up Teradata Clients
Configuring Network Name Resolution
Note: The default location of the hosts file on a Windows client machine is:
drive:\WINDOWS\system32\drivers\etc
If not already defined, these aliases must be created for every IP address occupied by the
Teradata Database system:
nnn.nnn.nnn.nnn
node_name
system_name_copn
dbccopn
Parameter
Description
nnn.nnn.nnn.nnn
The IP address of one of the Teradata Database system nodes.
node_name
The name by which the node is to be known on the network.
This is typically a numeric variation on the system name. For example, a
node of a Teradata Database system named saturn might be saturn4.
system_name_copn
The name by which the system is known on the network, followed by the
literal “cop”, followed by a number.
The numbers should start from 1 for the IP address of the first node of the
system, and increment by one for each successive IP address entry.
dbccopn
[Optional] The literal “dbccop” followed by a number that matches the
number used for the system_name_copn entry.
This entry allows database logons to have only a username and password,
and exclude the system name. It is purely a convenience for users who
manually log on to the system.
Note: If there are more than one Teradata Database systems on the
network, only one can have the dbccop aliases, so logons to only that system
can exclude the system name from the logon string.
Example Configuration
For a four-node Teradata Database system named saturn, with the first node having an IP
address of 240.141.34.101, the DNS tables for the network or the hosts file entries on every
client would define the following network aliases for the system node IP addresses:
240.141.34.101
240.141.34.102
240.141.34.103
240.141.34.104
saturn1
saturn2
saturn3
saturn4
saturncop1
saturncop2
saturncop3
saturncop4
dbccop1
dbccop2
dbccop3
dbccop4
The node names can use a different naming scheme, however the cop numbers must always
begin at 1 and increment by 1, and must all match for a given IP address:
240.141.34.101
240.141.34.102
240.141.34.103
240.141.34.104
satnode24
satnode34
satnode44
satadmin
saturncop1
saturncop2
saturncop3
saturncop4
dbccop1
dbccop2
dbccop3
dbccop4
or
240.141.34.101
240.141.34.102
240.141.34.103
240.141.34.104
70
lucy
ricky
fred
ethel
saturncop1
saturncop2
saturncop3
saturncop4
dbccop1
dbccop2
dbccop3
dbccop4
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Creating Environment Variables
Creating Environment Variables
Some Teradata Tools and Utilities programs employ the Call Level Interface (CLIv2) to access
the database. CLIv2 requires that you define some operating system environment variables.
1
Open the Windows Control Panel.
2
Double-click on System.
3
In the System Properties dialog, click the Advanced tab.
4
Click Environment Variables.
5
Under System Variables, click New.
6
For Variable Name enter COPLIB
7
For Variable Value enter C:\Program Files\Teradata\Client\14.0\CLIv2\
This is the path to the CLIv2 system parameter block file, clispb.dat.
8
Repeat steps 5 through 7 to create an environment variable named with the name of your
Teradata Database system. The variable value should be the number of nodes in the system
(those with IP addresses that were aliased in the previous task).
For the example saturn system used in the previous task, there would be a new
environment variable created named “saturn” with a variable value of 4.
Note: If you change any system environment parameters, you must reboot the client
computer for the changes to take effect.
Working with ODBC Data Sources
You must configure ODBC data sources so that:
•
Teradata Administrator, Teradata SQL Assistant, and other ODBC-based Teradata client
applications can use the Teradata ODBC driver to connect to Teradata Database. See
“Setting up Teradata as an ODBC Data Source” on page 71.
•
Teradata Parallel Transporter can use the DataDirect ODBC driver to connect to an
external ODBC data source. See “Setting Up an External ODBC Data Source” on page 73.
Setting up Teradata as an ODBC Data Source
An ODBC data source stores information about connecting to an ODBC-compliant database.
Perform this procedure on all Teradata clients to define and configure the Teradata data
source. The data source provides access to Teradata Database for ODBC-based applications,
such as Teradata Administrator, Teradata SQL Assistant, and third-party or customerdeveloped applications that use ODBC.
1
Open the Windows Control Panel.
2
Double-click Administrative Tools.
3
Double-click Data Sources (ODBC).
Teradata Data Warehouse Appliance 2690 Implementation Guide
71
Chapter 4: Setting Up Teradata Clients
Working with ODBC Data Sources
4
System data sources are available to all users of this machine. User data sources are
available only to the user logged in at the time the data source was defined. If all users of
this client machine will be using Teradata Tools and Utilities programs, click the System
DSN tab, otherwise click the User DSN tab.
5
Click Add.
6
In the Create New Data Source dialog, select Teradata from the list, then click Finish.
7
In the ODBC Driver Setup for Teradata Database dialog, enter the following:
Field
Recommended Setting
Name
Enter the name by which the Teradata Data Warehouse Appliance 2690
is known to the network. This is the name that will be displayed for the
ODBC data source.
Description
[Optional.] Enter a comment that describes the database system of this
data source.
Name(s) or IP
address(es)
Enter the name by which the Teradata Data Warehouse Appliance 2690
is known to the network.
Do not resolve alias
name to IP address
Leave this box checked.
The system name is resolved to an appropriate IP address when the
ODBC connection is made.
Use Integrated Security Leave this box unchecked.
Integrated Security allows the use of single sign-on, in which users are
authenticated by the network and are not required to submit a username
or password for subsequent access to Teradata Database.
Note: Integrated Security can be enabled for the Teradata ODBC data
source at any time by returning to this setup dialog box. However,
additional setup is required in the database to fully enable single signon. For more information, see Security Administration.
Mechanism
Choose TD2 from the drop-down list unless your site security policy
requires a different authentication mechanism.
For information on using other authentication methods, see Security
Administration.
Parameter
Leave this field blank, unless an authentication mechanism other than
TD2 was used.
If your site security policy requires a different authentication
mechanism, consult with your security or network administrator to
determine whether any authentication parameters are required.
Username
Enter the Teradata Database username for the client user, or if a user is
not yet assigned to the client, enter dbc (the default Teradata super user)
and change the name to the assigned client user at a later time.
For information on creating database users, see Chapter 5: “Setting up
Administrative Users,” and Chapter 10: “Setting Up Users.”
72
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Working with ODBC Data Sources
Field
Recommended Setting
Password
Leave this field blank. The system will prompt users for a password
when ODBC-mediated applications attach to the data source.
Note: Client applications that run operations in batch mode may
require an ODBC data source that has both a database username and
password specified in this dialog box. If you need to use such a client
application, create a separate Teradata ODBC data source, with a
different name (it need not match the system name) and enter the
password when setting up that data source. Use that data source when
you will be using the application to run batch mode operations.
Default Database
Leave this field blank.
The system will automatically use the default database specified in the
CREATE USER statement for the configured user.
For details on specifying the default database in a CREATE USER
statement, see “Working with Database Users” on page 179.
Account String
Leave this field blank.
To use account strings, you must specify accounts for individual users
with a CREATE USER or MODIFY USER statement. For information
on accounts, see Chapter 10: “Setting Up Users.”
Session Character Set
8
From the drop-down list, choose the character set that will be used for
each ODBC session. If you are unsure of the prevailing local character
set, leave the selection at ASCII.
Click OK to complete the configuration of the ODBC data source.
Note: If you need to change your ODBC connection later, you can enter the change in the
configuration screen for any ODBC-enabled utility, such as Teradata Administrator
File>Define Data Source>Configure, rather than here in the Teradata ODBC Driver Setup
dialog box. The change is automatically entered in the ODBC configuration and is in effect for
all ODBC-enabled utilities installed on that machine.
For more information on the Teradata ODBC driver, and for troubleshooting connection
problems, see ODBC Driver for Teradata User Guide.
Setting Up an External ODBC Data Source
If you plan to use Teradata Parallel Transporter (TPT) to load data into Teradata Database
from an external ODBC-compliant database (such as Oracle), you cannot use the Teradata
ODBC driver. Instead, you must purchase, install and configure the DataDirect ODBC driver.
1
Install the DataDirect ODBC driver software version 5.3 or later, according to
manufacturer instructions, only on the Teradata client(s) from which TPT jobs run.
2
When the DataDirect ODBC driver installation is complete, open the Windows Control
Panel.
3
Select Administrative Tools.
4
Select Data Sources (ODBC).
Teradata Data Warehouse Appliance 2690 Implementation Guide
73
Chapter 4: Setting Up Teradata Clients
Restarting the Client
5
In the Data Sources dialog box, click Add.
6
In the Create New Data Source dialog box, select DataDirect 6.1 Oracle Wire Protocol as the
driver for which you want to set up a data source.
7
In the Oracle Wire Protocol Driver Setup dialog box:
a
In the Data Source Name field, enter the DSNname of the Oracle system.
b
In the Description field, enter a description of the source, for example, Oracle System.
c
In the Host field, enter the machine name for the Oracle system, for example, Snorkel.
d
In the Port Number field, enter the port number on which the Oracle system listens.
e
In the SID field, enter the Oracle System ID, which is used to uniquely identify a
database on the Oracle system.
8
Click OK.
9
Click Finish.
Reference Information
Information on...
Is available in...
configuring the ODBC.ini files for using the
DataDirect ODBC Driver on a Unix client
the chapter about the ODBC Operator in Teradata
Parallel Transporter Reference
Restarting the Client
After configuring the software, restart the client computer.
Setting Up Teradata Clients to Access Teradata
Viewpoint
Teradata Viewpoint is the principal administrative interface with Teradata Database. All
database users should have access to at least some Teradata Viewpoint functions.
Initial connection of Teradata Viewpoint to the database is normally done by Teradata
Customer Service personnel, as part of installation and setup of the Teradata Data Warehouse
Appliance 2690 system.
Suggestions for setup and use of Teradata Viewpoint are covered in Chapter 12: “Monitoring
the Database” and Chapter 13: “Managing the Database.”
You may find it useful to complete the detailed set up of Teradata Viewpoint for individual
clients in stages, for example, set up:
•
74
User DBADMIN and other top-level administrative users as part of “Setting Up the
Database Administrator User” on page 87.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Setting Up Teradata Clients to Access Teradata Viewpoint
•
Database programmers and testers, prior to database implementation and testing, which
begins with Chapter 6: “Creating the Database Structure.”
•
Other users when completing Chapter 10: “Setting Up Users.”
Prerequisites for Setting up Teradata Viewpoint on Clients
•
The Teradata Viewpoint server is installed and configured for operation.
•
At least one administrative user is configured to access and administer Teradata
Viewpoint.
•
The Teradata Viewpoint logon user (viewpoint) exists in the database and has the
privileges necessary to execute database monitoring and management functions.
See Teradata Viewpoint Configuration Guide for instructions.
Requirements for Viewpoint Clients
Client computer recommendations:
•
2 Ghz (or better) dual core processor
•
1 GB memory
Computers that do not meet these recommendations may experience slow portlet load times,
and may limit the number of portlets that can be simultaneously accessed.
Teradata clients access Viewpoint using a web browser. Supported browsers are:
•
Mozilla Firefox 3.5 or 4.0 (recommended)
•
Internet Explorer 7 or 8
•
Google Chrome 10
•
Safari 5
Reference Information
Information on...
Is available in...
setup options Teradata Viewpoint
not covered in this publication
Teradata Viewpoint Configuration Guide
the full range of Teradata Viewpoint
portlets and options
Teradata Viewpoint Users Guide
using Teradata Viewpoint to
monitor and manage the database
• Chapter 12: “Monitoring the Database”
• Chapter 13: “Managing the Database”
Teradata Data Warehouse Appliance 2690 Implementation Guide
75
Chapter 4: Setting Up Teradata Clients
Checkpoint
Checkpoint
Before leaving Chapter 4: “Setting Up Teradata Clients,” make sure that:
√
Result
Reference
You have the complete client installation kit and
know which software should be installed on
administrative and non-administrative clients.
“Installation Guidelines” on page 64
Microsoft .NET Framework and .NET Data
Provider for Teradata are installed on Teradata
client machines.
“Installing Microsoft .NET Framework” on
page 66
TTU software is installed on all Teradata clients.
“Installing Teradata Tools and Utilities” on
page 66
The TTU software installation includes the
latest updates from Teradata @ Your Service.
“Using the Latest Software Updates” on
page 67
The Windows Help Program (required for
Windows Vista or later OS) is installed.
“Downloading the Windows Help
Program” on page 69
Every IP address occupied by the Teradata
Database system has a network alias defined.
“Configuring Network Name Resolution”
on page 69
Operating system environment variables are
defined for CLIv2, which several TTU programs
use to access the database.
“Creating Environment Variables” on
page 71
The Teradata data source and the external
ODBC data source is defined for the required
ODBC drivers.
“Working with ODBC Data Sources” on
page 71.
Clients where Teradata Tools and Utilities
software was installed were restarted.
“Restarting the Client” on page 74
The administrative clients are set up to access
Teradata Viewpoint
“Setting Up Teradata Clients to Access
Teradata Viewpoint” on page 74
If you do not have any result, review/rerun that procedure.
76
Teradata Data Warehouse Appliance 2690 Implementation Guide
SECTION 2
Database Implementation
Teradata Data Warehouse Appliance 2690 Implementation Guide
77
Section 2: Database Implementation
78
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 5
Setting up Administrative Users
This section provides administrative setup procedures that must be done prior to creating
databases and tables.
Implementation Task Overview
Setting up administrative users requires that you perform the following tasks completely and
in the order presented.
1
Configure basic administrative settings. See “Configuring Default Administrative Settings”
on page 79.
2
Configure disk space for system-level functions. See “Allocating Space for System-Level
Functions” on page 82.
3
Set up the Database Administrator user. See “Setting Up the Database Administrator User”
on page 87.
4
Set up Database Administrator privileges. See “Setting Up Database Administrator Access
to Teradata Viewpoint” on page 96.
Configuring Default Administrative Settings
Setting Up the Teradata Administrator GUI
1
From the principal administrative client configured in Chapter 4: “Setting Up Teradata
Clients,” access Teradata Administrator, click Start>Programs>Teradata Administrator.
2
The Please Select a Data Source dialog box appears. Do the following:
3
a
In the left field, highlight the alias name for the Teradata Data Warehouse Appliance
2690.
b
In the Root Database field enter DBC.
c
In What to Load, select All Databases and Users and click OK.
In the Teradata Database Connect dialog box do the following:
a
In the Username field enter DBC.
b
In the Password field, enter the user DBC password provided by your Teradata
Customer Service representative.
c
Do not change other fields. Click OK.
Teradata Data Warehouse Appliance 2690 Implementation Guide
79
Chapter 5: Setting up Administrative Users
Configuring Default Administrative Settings
4
Set Preview Mode as the default so that SQL statements generated from using the GUI
fields and controls will appear in the Query Window before the statement is executed.
a
From the Teradata Administrator menu, click Tools>Options.
b
Click the Confirmation tab.
c
Check the Preview SQL before submitting check box and click OK.
Note: Setting Preview Mode as the default is optional, but it will help new Teradata
Database users to become familiar with Teradata Database SQL statements. You can send
generated SQL without previewing it at any time by un-checking the Preview SQL before
submitting check box.
Defining the Data Directory
The Teradata Administrator data directory stores generated SQL for later reference and use.
The default location is:
Documents and Settings\Network_UserId\My Documents\Teradata\Teradata Manager\Data.
If you can use the default location, skip this procedure and go on to “Changing the
PasswordExpire Parameter.”
If you want to change the location, use the following procedure to relocate the data directory.
1
From the Teradata Administrator main window, click Tools>Options.
2
Click the Directory tab.
Note the following directory display fields:
3
•
Old Path - The current path to the data directory
•
New Path - The new path to the data directory
Navigate to the desired directory.
The directory path changes automatically in the New Path box.
4
Click OK to save your path changes and exit the dialog box.
Setting Global Default Values
Certain global database setting must be reset from the system default values. To minimize the
number of database restarts, make as many a s possible of the necessary changes to global
database settings at one time.
80
•
Enable the Lock Logging feature described in “Enabling Lock Logging” on page 81.
•
Set the values for some Locking Logger fields as shown in “Setting Up Lock Logging
Parameters” on page 226.
•
Reset the PasswordExpire parameter as shown in “Changing the PasswordExpire
Parameter,” to force the creation of a private password at first logon for user DBC and all
other subsequently created users.
•
To enable the new settings you must restart the database as shown in “Initiating a Manual
Restart” on page 248.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Configuring Default Administrative Settings
Enabling Lock Logging
Do the following to enable use of the Lock Logger feature described in “Investigating Query
Blocks and Delays” on page 229.
1
Log on to the Teradata Data Warehouse Appliance 2690 control node, as shown in
“Logging on to the Control Node” on page 239.
2
Open a cnsterm Supervisor Window, as shown in step 1 of “Running Database Utilities
from cnsterm” on page 238.
3
At the prompt, start the DBS Control utility:
start dbscontrol
4
Hold the Ctrl key while pressing the C key to exit the Supervisor Window.
5
At the Linux command prompt (#) start cnsterm again, this time specifying the
application window in which dbscontrol is running.
cnsterm 1
6
At the dbscontrol prompt, enter the following command and press Enter to enable
LockLogger:
MODIFY General 9 = TRUE
Note: The “9” specifies DBSControl field #9, which is LockLogger. Succeeding steps in this
procedure also specify field numbers, as required, instead of field names.
7
At the dbscontrol prompt, enter the following command to enable the LockLogger Delay
Filter:
MODIFY General 28 = TRUE
8
At the dbscontrol prompt, enter the following command to set the LockLogger Delay Filter
Time to 1 second:
MODIFY General 29 = 1
9
Exit cnsterm by pressing Ctrl-C. The new settings take effect immediately after the
database restart.
Reference Information
Reference topics are arranged according to the first step in which the topic appears.
For step...
Information on...
Is available in...
All
the use of Locking Logger
“Setting Up Lock Logging Parameters” on page 226.
Changing the PasswordExpire Parameter
This procedure forces the creation of a private password for user DBC and all other
subsequently created users:
1
Log on to Teradata Administrator as user DBC.
2
From the Teradata Administrator main screen, click on the Query button on the bottom of
the left menu bar. The Teradata SQL Assistant query window opens.
Teradata Data Warehouse Appliance 2690 Implementation Guide
81
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
Enter the following SQL into the query window and click the Run Query button
3
:
Update DBC.SysSecDefaults SET ExpirePassword = 90
Setting the PasswordExpire value to a non-zero number of days causes temporary
passwords, including the user DBC password, to expire at the first logon and forces all
users to create a private password. The password for each user then expires each time the
increment of days passes.
Ninety days is a typical setting. Specify a different value for this and other password
controls if required by your site security policy.
4
Click File/Exit to close the Teradata SQL Assistant application. Click Yes at the prompt.
5
Click File>Exit to close Teradata Administrator. The Save Changes prompt appears. For
this and other procedures, click Yes if you want to save the changes to the directory defined
in “Defining the Data Directory” on page 80.
6
Restart the database to enable the new password expiration setting, as shown in “Initiating
a Manual Restart” on page 248.
Note: This also enables the Locking Logger parameter changes made in “Enabling Lock
Logging” on page 81.
7
When the database completes the restart, log on to Teradata Administrator as user DBC.
8
At the prompt create a private password for user DBC.
Note: When a user password expires, the user automatically has the privilege to specify a new
password using the MODIFY USER statement.
Reference Information
Reference topics are arranged according to the step in which the topic appears.
For step...
Information on...
Is available in...
2, 7 and 8
password control options
and how to set them,
password format
requirements, and other
password features
Chapter 6: “Managing Database Passwords,” in Security
Administration
4
the data directory location
“Defining the Data Directory” on page 80.
5
restarting the database
“Initiating a Manual Restart” on page 248.
Allocating Space for System-Level Functions
All storage space available to Teradata Database is initially owned by the system-generated
user DBC, and must be reallocated to individual users and databases.
82
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
About Database Space
You must allocate two types of database space:
•
Permanent space (perm space): Space for storing the data is allocated to the user or
database that owns the table containing the data.
•
Spool space: Temporary work space used by running queries. Spool space is automatically
drawn from any space that is not being used to store data.
Database space must first be allocated to system-generated users, then to administrators, and
finally to databases. Allocating space to an end user is optional depending on the type of
activities the user performs in the database.
For information on allocating user space, see“Working with Database Users” on page 179.
About System-Generated Users
During initial setup, the Teradata Data Warehouse Appliance 2690 generates several default
users and assigns them perm space.
Note: The system also creates other default users, but they need not be considered for the
initial allocation of system space.
System Generated User
Function
Perm Space Default
Crashdumps
Temporarily stores PDE memory
dumps.
~1 GB
Contains:
Initially owns all usable disk
space. After you allocate space to
databases and other users, some
perm space must remain
assigned to user DBC (~10% of
available space).
DBC
•
•
•
•
Data Dictionary tables
Views and macros
System tables
Logs and transient journals
Can be reset per site needs.
Note: DBC space is not usable
for database administration
functions.
SysAdmin
Contains tables, views and macros for
network-based load jobs.
~40 MB
Sys_Calendar
Contains tables and views for daterelated functions.
~15 MB
SystemFe
Contains diagnostic tables and
macros for use by Teradata Customer
Service.
~60 MB
Note: Do not reuse the
name SysAdmin.
Teradata Data Warehouse Appliance 2690 Implementation Guide
83
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
Required System-Level Space Allocation Tasks
1
Create the spool space reserve. See Creating the Spool Space Reserve.
2
Optimize perm space for the crashdumps database according to site needs. See “Assigning
Perm Space to Crashdumps” on page 85.
Creating the Spool Space Reserve
Before assigning permanent space to users and databases, create the spool space reserve from
the space available to user DBC, to ensure that there will be enough free space to run queries.
If system-wide use of spool space exceeds the spool reserve, the system draws needed spool
space from uncommitted DBC perm space.
Note: When you specify spool space in CREATE USER or CREATE PROFILE statements, you
define the maximum spool that is available to users or profile members
The following procedure sets the spool space reserve at a nominal 20% of total available space,
which you may need to adjust later, depending on the number of simultaneous queries and
the size of the tables in the database.
1
2
Determine the perm space owned by user DBC:
a
On the Teradata Administrator main screen, click Tools>Modify User. The Modify
User screen appears.
b
Read the number in the Perm Space dialog box, for example 6347.75 GB, and note
which of the three boxes, KB, MB, and GB is checked.
Calculate a value in bytes equal to 20% of the DBC space, using the number obtained in
step 1, to set aside as spool space reserve, for example:
(6347.75 GB) *(.20) = 1269.55 GB
Write down this number for use in step 5.
84
3
Close the Modify User dialog box.
4
On the Teradata Administrator main screen, click Tools>Create>Database.
5
In the Create Database Dialog Box, enter the following:
a
For the Database Name field enter Spool_Reserve.
b
For the Owner field enter DBC, the owner of the space in which you are creating the
Spool_Reserve database.
c
For the Perm Space field, enter the value calculated in step 2. You can express the value
in KB, MB (the default), or GB, depending on which of these is selected. The value
displays in bytes.
d
Check FallBack. Before Journal and After Journal are checked No by default.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
e
Click Create to create the Spool_Reserve database.
The Query Window displays the generated CREATE DATABASE statement, for
example:
CREATE DATABASE "Spool_Reserve" FROM "DBC"
AS PERM = perm_space
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
where the perm_space shown is the amount of space, in bytes, entered in the Perm
Space field.
6
f
From the Query window, click the Run Query button
g
Close the Query window and the Create User dialog box.
.
To view information about the new database:
a
Expand database DBC in the left pane of the main Teradata Administrator screen.
b
Click the New Database Host icon to refresh the display.
c
Select the Spool Reserve database.
d
Open the Database menu at the top of the screen.
e
Select Database Information to display the characteristics of the Spool Reserve
database.
Note: Periodically monitor space utilization and adjust space allocations as necessary, as
shown in “About Space Management” on page 217.
7
Keep Teradata Administrator open for use in the Assigning Perm Space to Crashdumps.
Reference Information
Reference topics are arranged according to the first step in which the topic appears.
For step...
Information on...
Is available in...
5
the CREATE DATABASE
statement
SQL Data Definition Language Syntax and Examples
strategy and tools for
managing space
utilization
• “About Space Management” on page 217.
• Teradata Viewpoint User Guide
• Database Administration
Assigning Perm Space to Crashdumps
Assign perm space to the system-defined crashdumps user to contain PDE memory dumps, as
follows.
1
Calculate optimal perm space for the crashdumps database using the formula:
Crashdumps Perm Space = (Number of TPA Nodes) * (Memory in GB per node) * (6)
Teradata Data Warehouse Appliance 2690 Implementation Guide
85
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
Note: To verify the number of nodes, navigate to the SMWeb Home page, click SMClient,
and refer to the Tree View, as shown in “Tree View” on page 49.
This equation is based on the following assumptions:
•
32 GB of memory per node
•
a crashdump uses approximately 50% of node memory capacity
•
allocate space for at least 3 crashdumps
•
specifying FALLBACK protection for tables (the default) doubles the required space
For a 4 node system, the calculation would look similar to the following:
Crashdumps Perm Space = (4) * (32 GB) * (6), or 768 GB.
Note: Crashdumps appear as table images and will accumulate as long as there is available
space. They are used by Teradata Customer Support to investigate crashes. You must
remove crashdump files manually.
2
Modify the crashdumps default perm space value from the 1 GB default to the calculated
value by doing the following:
a
Log on to Teradata Administrator as user DBC.
b
In the left pane of the main screen select the crashdumps database.
c
At the top of the Teradata Administrator main screen click Tools>Modify User.
d
For the Perm Space field, select GB (the default is MB), and enter the amount of perm
space in GB for the crashdumps database, as calculated in step 1.
e
Retain all default settings. Click Modify.
The Query Window pops up and displays the generated MODIFY USER statement,
for example:
MODIFY USER "Crashdumps" AS
PERM= perm_space
STARTUP = ''
FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
COLLATION = HOST
DEFAULT CHARACTER SET = LATIN
DATEFORM = INTEGERDATE
TIME ZONE = NULL
where the perm_space shown is the amount of space, in bytes, entered in the Perm
Space field.
Note: Some options appear in the SQL that were not specified in the procedure. They
are system defaults and should be left as they are.
f
From the Query window, click the Run Query button
g
Close the Query window and the Modify User dialog box.
.
Note: Periodically monitor space utilization and adjust space allocations as necessary, as
shown in “About Space Management” on page 217.
86
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
3
Keep the Teradata Administrator utility open for use in the Setting Up the Database
Administrator User.
Reference Information
Reference topics are arranged according to the first step in which the topic appears.
For step...
Information on...
Is available in...
1 and 2
the use and maintenance of the
crashdumps database
“Handling Teradata Crashdumps,” in Database
Administration
details about perm space
“Managing Space,” in Database Administration
the MODIFY DATABASE
statement
SQL Data Definition Language Syntax and
Examples
2
Setting Up the Database Administrator User
Create the principal database administrator, user DBADMIN (or the name your site uses), and
grant space and privileges to the user before proceeding with database implementation. User
DBADMIN can then create databases, tables, users, and other objects in the space it owns.
Note: For larger systems, you may find it useful to create additional administrative users to
share database administration duties. See the sections beginning with “Administrative Users”
in Chapter 3 of Security Administration.
Required Database Administrator Setup Tasks
1
Create the database administrator profile. See “Creating the DBADM Profile” on page 87.
2
Create the principal database administrator. See “Creating User DBADMIN” on page 89.
3
Grant database privileges to the principal database administrator. See “Granting Database
Privileges to User DBADMIN” on page 91.
4
Provide Teradata Viewpoint privileges to the administrator. See “Setting Up Database
Administrator Access to Teradata Viewpoint” on page 96.
Creating the DBADM Profile
Profiles determine certain system resources available to member users, and can also set
password control parameters.
1
From an administrative client configured in Chapter 4: “Setting Up Teradata Clients,” log
on to Teradata Administrator as user DBC.
2
Create the profile for the database administrator, user DBADMIN:
a
From the menu, click Tools>Create>Profile.
b
Specify values for the following fields and controls:
Teradata Data Warehouse Appliance 2690 Implementation Guide
87
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Note: Do not enter values at this time for fields not listed.
Field
Description
Profile Name
Required. The name of the database administrator profile.
Recommendation: Administrative procedures in this publication use the name
DBADM for the administrator profile.
Note: User DBADMIN will be the only member of this profile. Because of
space and ownership concerns, you must create a separate profile for other
administrative users.
On the General tab...
Account
Optional. An account string defines the following characteristics for profile
member sessions in the database:
• Session priority
• Account ID (to assign charges for system time and resources)
• Date stamp
• Time stamp
Recommendation: Define at least one account string per profile. If necessary,
you can add an account string later using a MODIFY PROFILE statement.
For more about accounts, see the sections beginning with “Working with User
Accounts” on page 173.
Password
Required. The temporary password for DBADMIN.
Recommendation: Create a simple temporary password. Each user is
prompted to change the temporary password to a permanent, private password
at first logon to the database.
Spool Space
Optional. The spool space specification is only a limit to the amount of space
available for intermediate query results or formatted answer sets to queries and
volatile tables. The system borrows spool space for a user from unused
permanent space anywhere in the system.
Recommendation: Set this value equal to the amount of space in the
Spool_Reserve database defined in “Allocating Space for System-Level
Functions” on page 82.
Temporary
Space
Not applicable. Required only when using global temporary tables and other
advanced features.
Recommendation: Temporary space specification is not normally needed.
Specification of temporary space requires that you develop a strategy for use of
the advanced features that need temporary space. If necessary, you can add a
temporary space specification later with a MODIFY USER statement.
Comment
Optional. Use this space to describe the profile or note contingencies. The
string has a 255 character limit.
On the Password tab...
Expire
Required. The number in days until a password expires. Set this value to a
positive, non-zero number to cause passwords to expire.
Recommendation: 90 days is a common password expiration interval.
88
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Field
Description
Other
password
controls
Optional.
Recommendation: Set other password controls globally, by updating the
DBC.SysSecDefaults, if required by your site security policy.
Note: Be sure to review the default password control values to determine
whether they conform to your site security requirements.
For information on the default password control values and how to change
them, see Chapter 6: “Managing Database Passwords,” in Security
Administration.
c
Do not use the Users in Profile dialog box. You can specify profile membership in
“Creating User DBADMIN.”
d
Click the Create button to create the profile. The Query Window displays a generated
CREATE PROFILE statement similar to the following:
CREATE PROFILE "dbadm" AS
SPOOL=spool_space
TEMPORARY=NULL
ACCOUNT=('$H-DBC-MANAGER',' account__str2',' account_str3')
DEFAULT DATABASE="All"
PASSWORD = password
(EXPIRE=90,MINCHAR=NULL,MAXCHAR=NULL,MAXLOGONATTEMPTS=NULL,LOCKEDU
SEREXPIRE=NULL,REUSE=NULL,DIGITS=NULL,RESTRICTWORDS=NULL,SPECCHAR=
NULL)
e
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
f
Close the Query Window and the Create Profile dialog box.
Reference Information
For step...
Information on...
Is available in...
2
setting up user accounts
“Working with User Accounts” on page 173.
the default password control
values and how to change them
Security Administration
Creating User DBADMIN
1
From an administrative client configured in Chapter 4: “Setting Up Teradata Clients,” log
on to Teradata Administrator as user DBC.
2
Create the database administrator as follows:
a
From the menu, click Tools>Create>User.
b
Specify values for the following fields and controls:
Note: Do not enter values at this time for fields not listed.
Teradata Data Warehouse Appliance 2690 Implementation Guide
89
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Field
Description
User Name
Required. The name of the database administrator user.
Recommendation: All administrative procedures in this publication use the
name DBADMIN for the principal administrator.
Owner
The owner of user DBADMIN, that is, DBC.
Password
Required. The temporary password for DBADMIN.
Recommendation: Any simple password will work that follows the default
system password controls. Each user is prompted to change the temporary
password to a permanent, private password at first logon.
Note: Be sure to review the default password control values to determine
whether they conform to your site security requirements.
For information on password control options, see Security Administration.
Permanent
Space
Required. The space in bytes that contains all objects that user DBADMIN
creates or owns. Because user DBADMIN will create and own nearly all Teradata
databases and tables, assign it the majority of space on the system.
Recommendation: 60-65% of available system (DBC) space. For information
on how to determine DBC space, see step 1 on page 84.
Spool Space
Optional. The spool space specification is only a limit to the amount of space
available for intermediate query results or formatted answer sets to queries and
volatile tables. The system borrows spool space for a user from unused
permanent space anywhere in the system.
Recommendation: Spool space specification is not normally needed. Spool is
already allocated in the DBADM profile.
Default
Database
Optional. The user or database containing the space in which the Teradata
Database stores or searches for new or target objects unless a different database
is specified in the transaction SQL.
Recommendation: Specify DBADMIN.
Profile
Required. The name of the profile in which the user has membership. A user can
be a member of only one profile.
Recommendation: Enter DBADM, the profile created for user DBADMIN in
Creating the DBADM Profile.
FALLBACK
Optional. Specification of FALLBACK automatically creates a duplicate of each
table stored in the user space, in addition to the duplicates already created by
disk mirroring, to which the system can revert in the event of a failure.
Recommendation: Uncheck Fallback. FALLBACK is only recommended for
individual mission-critical tables or tables so large that their size prevents timely
backup to tape or external disk.
Note: You can adjust the space assignments if required, using the Modify User GUI.
c
90
Click Create.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
The Query Window pops up and displays the generated CREATE USER statement, for
example:
CREATE USER "DBADMIN" FROM "DBC"
AS PERM = perm_space
PASSWORD = "temp"
SPOOL = spool_space
PROFILE = DBADM
STARTUP = ''
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
Note: Some options appear in the SQL that are not specified in the procedure. These
are system defaults and should remain as they are. For example Before Journal and
After Journal are checked No by default.
3
d
From the Query window, click the Run Query button
e
Close the Query window and the Create User dialog box.
.
Keep the Teradata Administrator utility open for use in the “Granting Database Privileges
to User DBADMIN” on page 91, or close the utility by clicking File>Exit.
Note: After you create the administrative user DBADMIN, do not log on as user DBC to
perform subsequent administrative activities except during activities that only user DBC can
perform.
Reference Information
Reference topics are arranged according to the first step in which the topic appears.
For step...
Information on...
Is available in...
1
logon to Teradata Administrator
“Configuring Default Administrative Settings”
on page 79.
2
user types and characteristics
Chapter 5: “Creating Users and Granting
Privileges,” in Security Administration
syntax and options for the
CREATE USER statement
SQL Data Definition Language Syntax and
Examples
guidelines for managing of space
“Managing Space,” in Database Administration
the default password control
values and how to change them
Chapter 6: “Managing Database Passwords,” in
Security Administration
Granting Database Privileges to User DBADMIN
1
Log on to Teradata Administrator as user DBC.
2
Grant object access privileges to system tables and other objects owned by user DBC.
a
From the main window, click Tools>Grant/Revoke>Object Rights.
b
Specify values for the following fields:
Teradata Data Warehouse Appliance 2690 Implementation Guide
91
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Field
Description
Database Name
The name of the user or database that owns the objects on which the
privileges are being granted.
Select DBC from the Database Name drop down list.
Object Type
The object on which the privileges are given.
Select Database from the Object Type drop down list.
To/From User
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
Normal
Specifies the privileges granted to the user. Check the following boxes:
• Execute
• Select
Grant
Specifies that the user is granted the WITH GRANT OPTION privilege,
that is the user can grant the privileges to other users.
Check the Grant box.
c
Click the Grant button.
The Query window appears and displays the generated GRANT statement:
GRANT
3
EXECUTE, SELECT ON "DBC" TO "DBADMIN" WITH GRANT OPTION.
d
From the Query window, click the Run Query button
e
Close the Query window.
.
Grant object-level database privileges to the database administrator on all objects
subsequently created in DBADMIN space.
a
From the main window, click Tools>Grant/Revoke>Object Rights.
b
Specify values for the following fields:
Field
Description
Database Name
The name of the user or database that owns the objects on which the
privileges are being granted.
Select DBADMIN from the Database Name drop down list.
Object Type
The object on which the privileges are given. Includes all databases and
all objects created in the database(s).
Select Database from the Object Type drop down list.
To/From User
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
92
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Field
Description
All
Specifies all rights for all objects created in DBADMIN space.
Check the All box.
Grant
Specifies that the user is granted the WITH GRANT OPTION privilege,
that is the user can grant all included privileges to other users.
Check the Grant box.
c
Click the Grant button.
The Query window appears and displays the generated GRANT statement.
GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, STATISTICS, DUMP,
RESTORE, CHECKPOINT, SHOW, EXECUTE PROCEDURE, ALTER PROCEDURE,
EXECUTE FUNCTION, ALTER FUNCTION, ALTER EXTERNAL PROCEDURE, CREATE
OWNER PROCEDURE, CREATE TABLE, CREATE VIEW, CREATE MACRO, CREATE
DATABASE, CREATE USER, CREATE TRIGGER, CREATE PROCEDURE, CREATE
FUNCTION, CREATE EXTERNAL PROCEDURE, CREATE AUTHORIZATION, DROP
TABLE, DROP VIEW, DROP MACRO, DROP DATABASE, DROP USER, DROP
TRIGGER, DROP PROCEDURE, DROP FUNCTION, DROP AUTHORIZATION ON
"DBADMIN" TO "DBADMIN" WITH GRANT OPTION;
4
d
From the Query window, click the Run Query button
e
Close the Query window.
.
Grant object-level privileges on DBC tables and views to DBADMIN.
a
From the main window, click Tools>Grant/Revoke>Object Rights.
b
Specify values for the following fields:
Field
Description
Database Name
The name of the user or database that owns the objects on which the
privileges are being granted.
Select DBC from the Database Name drop down list.
Object Type
The object on which the privileges are given. Includes all databases and
all objects created in the database(s).
Select Database from the Object Type drop down list.
To/From User
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
Access
Specifies privileges for all DBC tables and views.
Check the Access box.
Grant
Specifies that the user is granted the WITH GRANT OPTION privilege,
that is the user can grant all included privileges to other users.
Check the Grant box.
Teradata Data Warehouse Appliance 2690 Implementation Guide
93
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
c
Click the Grant button.
The GRANT statement generates and automatically submits the following SQL
statements without previewing them.
GRANT EXECUTE, SELECT, STATISTICS, SHOW ON "DBC" TO "DBADMIN" WITH
GRANT OPTION
5
d
From the Query window, click the Run Query button
e
Close the Query window.
.
Grant additional system-level privileges not included with the object-level privileges
granted in step 4:
a
Deselect the Preview Mode button at the top of the main screen. The sub-procedure
that follows generates a compound SQL statement that cannot be submitted from
Preview Mode.
b
From the main window, click Tools>Grant/Revoke>System Rights.
c
Specify values for the following fields:
Field
Description
To/From User
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
All
Specifies all rights for all objects created in DBADMIN space.
Check the ALL box.
Grant
Specifies that the user is granted the WITH GRANT OPTION privilege,
that is the user can grant all included privileges to other users.
Check the Grant box.
d
Click the Grant button.
The GRANT statement generates and automatically submits the following SQL
statements without previewing them.
GRANT MONRESOURCE, MONSESSION, ABORTSESSION, SETSESSRATE,
SETRESRATE, REPLCONTROL, CREATE PROFILE, CREATE ROLE, DROP PROFILE,
DROP ROLE TO "DBADMIN" WITH GRANT OPTION;
GRANT UDTTYPE, UDTMETHOD ON SYSUDTLIB TO DBADMIN WITH GRANT OPTION;
e
6
94
Close the Grant/Revoke System dialog box.
Grant additional system-level privileges not covered by GRANT shown in step 5.
a
Click the Query button, the lowest button on the left edge of the main screen to open
the Teradata SQL Assistant query window. This allows you to construct and submit an
SQL statement without using the GUI interface.
b
Enter the following SQL statement:
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
GRANT CTCONTROL ON "DBADMIN" TO "DBADMIN" WITH GRANT OPTION;
c
7
Click the Run Query button
.
Grant privileges on Sys_Calendar, which contains tables and views for date-related system
functions.
a
Click the Preview Mode button to enable previewing SQL statements before
submitting them.
b
From the main window, click Tools>Grant/Revoke>Object Rights.
c
Specify values for the following fields:
Field
Description
Database Name
The name of the user or database that owns the objects on which the
privileges are being granted.
Select Sys_Calendar from the Database Name drop down list.
Object Type
The object on which the privileges are given. Includes all databases and
all objects created in the database(s).
Select Database from the Object Type drop down list.
To/From User
The name of the user that receives the privileges.
Select DBADMIN from the To/From User list.
Normal
Allows specification of rights for the named objects.
Check the Select, Insert, Update, and Delete boxes.
Grant
Specifies that the user is granted the WITH GRANT OPTION privilege,
that is the user can grant all included privileges to other users.
Check the Grant box.
d
Click the Grant button. The Query window appears and displays the generated SQL
statement.
GRANT SELECT, INSERT, UPDATE, DELETE ON "Sys_Calendar" TO "DBADMIN"
WITH GRANT OPTION;
8
e
From the Query window, click the Run Query button
f
Close the Query window and the Grant/Revoke Object dialog box.
.
Click File>Define Data Source. The ODBC Data Source Administrator box appears.
a
On the System DSN tab select the data source, that is, the system name.
b
Click on the Configure button. The ODBC Driver Setup for Teradata Database dialog
box appears.
c
Change the value of the Username parameter to DBADMIN.
Teradata Data Warehouse Appliance 2690 Implementation Guide
95
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
d
Change the value of the password to the temporary password for DBADMIN specified
in step b of “Creating User DBADMIN.”
Note: User DBADMIN will be prompted to change the temporary password to a
permanent, private password at first logon.
9
e
Click Yes to store the password, then click OK.
f
Click OK to exit the ODBC Data Source Administrator dialog box.
Click File>Exit to close Teradata Administrator.
10 Immediately reopen Teradata Administrator, which logs on to Teradata Database as
DBADMIN using the temporary password specified in Step 9 substep d.
Note: You do not need to execute a GRANT LOGON statement for user DBADMIN or
any other user created in the database. All users automatically have the right to log on to
the database from any connected client, unless a REVOKE LOGON statement is issued.
11 When prompted, create a private password for user DBADMIN. This client is now
configured for use by user DBADMIN. Conduct all future administrative tasks as user
DBADMIN or another administrative user.
12 Exit Teradata Administrator by entering File>Exit, or continue on to the next section,
“Setting Up Database Administrator Access to Teradata Viewpoint.”
Reference Information
Reference topics are arranged according to the first step in which the topic appears.
For step...
Information on...
Is available in...
1
logon to Teradata Administrator
“Configuring Default Administrative Settings”
on page 79.
2
system views
Data Dictionary
3
user privileges
Chapter 5: “Creating Users and Granting
Privileges” in Security Administration.
2 through 6
syntax and options for GRANT
(SQL form) and (Role form)
SQL Data Control Language
10
password format rules
Chapter 6: “Managing Database Passwords,” in
Security Administration
Setting Up Database Administrator Access to Teradata Viewpoint
DBADMIN and other administrative users can benefit from using Teradata Viewpoint to
monitor and manage the database during implementation. Do the following to provide
administrator access to Teradata Viewpoint.
96
1
Set up administrator client computers as shown in Chapter 4: “Setting Up Teradata
Clients.”
2
Create Teradata Viewpoint administrative users and assign roles, as shown in “Setting Up
Teradata Viewpoint Users” on page 211.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 5: Setting up Administrative Users
Checkpoint
Checkpoint
Before leaving Chapter 5: “Setting up Administrative Users,” make sure that:
√
Result
Reference
The Teradata Administrator GUI is set up on the
principal administrative client.
“Setting Up the Teradata Administrator
GUI” on page 79.
The DBS Control utility fields related to the use
of Locking Logger are reset from the default
values.
“Enabling Lock Logging” on page 81.
The PasswordExpire parameter is reset and the
database restarted to apply the new values.
“Changing the PasswordExpire
Parameter” on page 81.
Crashdumps has perm space assigned to it.
“Assigning Perm Space to Crashdumps”
on page 85.
There is a spool space reserve.
“Creating the Spool Space Reserve” on
page 84.
An administrative user called DBADMIN, exists
in the database and has:
“Setting Up the Database Administrator
User” on page 87
• A profile
• The database privileges necessary to carry out
database administrator duties
User DBADMIN has access to Teradata
Viewpoint.
“Setting Up Database Administrator
Access to Teradata Viewpoint” on
page 96
If you do not have these results, return to the section in the Reference column and review/
rerun that procedure.
Teradata Data Warehouse Appliance 2690 Implementation Guide
97
Chapter 5: Setting up Administrative Users
Checkpoint
98
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 6
Creating the Database Structure
This section describes the methodology for creating the primary database structure, that is,
databases, data tables, and views.
Database Implementation Overview
1
Create the top level databases that contain all other database objects. See “Working with
Databases” on page 99.
2
Design and create tables to contain data. See “Working with Tables” on page 106.
3
Design and create views to provide user access to data while limiting access to data tables.
See “Working with Views” on page 117.
4
Optionally use the Basic Teradata Query Utility (BTEQ) for database object creation. See
“Working with the Basic Teradata Query Utility” on page 122.
About the Database Structure
In Teradata Database, you must create database objects to contain other objects such as data
tables, indexes, views, and macros, as well as users and other lower level databases. The disk
space that you assign to a database determines the size and number of objects it can contain.
Databases implicitly own and have privileges on all objects created within their assigned space.
Individual objects contained in a database do not require a space allocation, but you can
specify space limits for some objects.
Working with Databases
About Top Level Databases
To ensure data integrity, Teradata recommends that only administrators and high-level users
have the privilege to access data tables. All other database activity should be done in views.
Teradata recommends that you create top level databases to separate tables and views You can
create additional lower level databases within the top level databases as required by site
security policy and user access needs.
Teradata Data Warehouse Appliance 2690 Implementation Guide
99
Chapter 6: Creating the Database Structure
Working with Databases
Database
Description
Tables_Database(s)
• Owns perm space.
• Contains all tables and data.
• Normally accessible only to privileged administrative and batch users for:
• Creating and modifying database objects
• Performing data loads and updates
Views_Database(s)
• Requires minimal perm space because it does not contain data.
• Contains views of the tables in the Tables_Database.
• Exists primarily to provide SELECT access to the data for all users.
Note: Where security policy requires it, you can designate a layer of views
for load and update operations so that even batch users do not need to
directly access data tables.
Creating the Tables Database
Use the following procedure to create the Tables Database that will contain all data tables.
1
Start Teradata Administrator and log on as user DBADMIN.
2
From the main screen, click the Preview Mode button
3
Click Tools>Create>Database. The Create Database dialog box appears.
4
Specify values for the following database parameters.
to display generated SQL.
Syntax Element
Explanation
Database Name
Required. The name of the master database containing all tables and data.
Recommendation: Use a name that provides a hint about the function of the
database, for example, Tables, Tables_Database, or TBL_DB.
Owner
Required. The name of the user or database that owns the space in which the
object is being created.
Recommendation: Enter the name of the primary administrative user,
DBADMIN, previously set up in “Creating User DBADMIN” on page 89.
Permanent
Required. The permanent space in bytes allocated to contain tables and other
objects created in the database.
Recommendation: For the Tables database, enter a value equivalent to 80% of
permanent space allocated to user DBADMIN.
If you create child databases within the Tables database, divide the Tables
database perm space among them according to the size of the tables each
database contains.
Note: Tables do not have perm space allocations. They automatically take the
space required to contain their data from the owning database.
100
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Databases
Syntax Element
Explanation
Spool
Recommendation: Not applicable. Queries running against the Tables database
draw spool from the spool reserve of the user.
Temporary Space
Not applicable. Required only when using global temporary tables and other
advanced features.
Specifying temporary space requires that you develop a strategy for use of the
advanced features that need such space. If necessary, you can add a temporary
space specification later with a MODIFY DATABASE statement.
Account
Not applicable.
Recommendation: Specify accounts at the profile or user level. For information
on using accounts, see “Working with User Accounts” on page 173.
Default Journal
The default location for journal images of tables created in the new or modified
database.
Recommendation: Specify only if you use journaling. See the syntax elements
Before Journal and After Journal in this table.
Comment
Optional. You can enter text to describe the database.
Before Journal
Specifies journaling for “before” change row images as follows:
• Yes - specifies a single journal.
• No - specifies no journal.
• Dual - specifies dual journals.
These are actual journaling requirements when specified in the Create Database
dialog box.
This option is not normally specified for the initial database implementation.
After Journal
Specifies journaling for “after” change row images as follows:
•
•
•
•
Yes - specifies a single journal on a different AMP from changed row.
No - specifies no journal.
Dual - specifies dual journals.
Local - specifies a single journal on the same AMP as changed row. The
Local option is only available for non-FallBack tables.
These are actual journaling requirements when specified on the Create
Database dialog box.
This option is not normally specified for the initial database implementation.
FallBack
Not applicable, but enabled by default. Specifies that the system will
automatically create a duplicate of each table stored in the database space, to
provide backup in the event of a failure.
Recommendation: Uncheck the FallBack box. Fallback is required only for
individual mission-critical tables or tables so large that their size prevents
timely backup to tape or external disk.
Note: This example is the minimum recommended specification for creating the
Tables_Database. You can specify additional options later using the MODIFY DATABASE
statement.
Teradata Data Warehouse Appliance 2690 Implementation Guide
101
Chapter 6: Creating the Database Structure
Working with Databases
Click the Create button to create the database. The Query Window displays a generated
CREATE DATABASE statement similar to the following:
5
CREATE DATABASE "Tables_Database" FROM "DBADMIN"
AS PERM = 104857600
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
6
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
7
Close the Query Window and the Create Database dialog box.
8
You can optionally create additional child databases within the Tables database to group
tables by function or department, but it is not required.
Reference Information
For step...
Information on...
Is available in...
All
options for setup and operation of
Teradata Administrator
Teradata Administrator User Guide
3 and 4
syntax and options for:
• SQL Data Definition Language Syntax
and Examples
• SQL Data Definition Language Detailed
Topics
•
•
•
•
4
CREATE DATABASE
DELETE DATABASE
DROP DATABASE
MODIFY DATABASE
guidelines for determining database
space requirements
Database Administration
Creating the Views Database
Use the following procedure to create one or more Views Databases to contain all the views
and macros required by the users. For information on creating individual views, see “Working
with Views” on page 117.
102
1
Start Teradata Administrator and log on as user DBADMIN.
2
From the main screen, click the Preview Mode button
SQL.
3
Click Tools>Create>Database. The Create Database dialog box appears.
to specify display of generated
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Databases
4
Specify values for the following database parameters.
Syntax Element
Explanation
Database Name
The name of the master database containing user-accessible views. To make data
more easily accessible you can create several Views databases according to the
needs of various departments or user groups, for example:
• Views by department
• Finance_Views
• Personnel_Views_and_Macros
• Purchasing_Views
• Views by user type
• General_User_Views
• Update_User_Views
• Batch_User_Views
You can also create Views databases by functional layer, for example:
• A layer of read-write views where each view mirrors a table, usable for batch
loads and updates without direct access to data tables
• A layer of read-only views that contain selected columns from one or more
tables to combine related information from multiple tables or restrict access
For information on the creation of views, see “Working with Views” on
page 117.
For a description of user types, see “About User Requirements” on page 171.
Owner
Required. The name of the user or database that owns the space in which the
object is being created.
Recommendation: Enter the name of the primary administrative user,
DBADMIN, previously set up in “Creating User DBADMIN” on page 89.
Permanent
Space
The permanent space in bytes allocated to contain space-consuming objects
created in the database.
Recommendation: The Views database is not meant to contain data, but it is the
best place to locate stored procedures that access the views. You can allocate a
small amount of permanent space for stored procedures, for example 100 MB,
and then adjust the allocation later using the MODIFY DATABASE statement.
Spool Space
Not applicable. Queries running in the Views database take spool space from the
Spool_Reserve database.
Temp Space
Not applicable.
Account
Not applicable.
Recommendation: Specify account at the profile or user level.
For information on using accounts, see “Working with User Accounts” on
page 173.
Default Journal
Not applicable.
Recommendation: Not applicable, because journaling is not specified for views.
Comment
Optional. You can enter text to describe the database.
Teradata Data Warehouse Appliance 2690 Implementation Guide
103
Chapter 6: Creating the Database Structure
Working with Databases
Syntax Element
Explanation
Before Journal
Not applicable.
After Journal
Not applicable.
FALLBACK
Not applicable. Fallback is required only for individual mission-critical tables or
tables so large that their size prevents timely backup to tape or external disk, and
this database contains only views of the data tables.
Recommendation: Uncheck Fallback box.
Note: This example is the minimum recommended specification for creating a
Views_Database. You can specify additional database options in the initial CREATE
DATABASE statement, or add them later using the MODIFY DATABASE statement.
Click the Create button to create the database. The Query Window displays a generated
CREATE DATABASE statement similar to the following:
5
CREATE DATABASE "Views" FROM "DBADMIN"
AS PERM = 0
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
6
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
7
Close the Query Window and the Create Database dialog box.
8
Grant access privileges to the Views database, as shown in “Working with Table Access
Privileges for Views” on page 105. After completing the procedure, return to this section
and continue with the remaining tasks.
Reference Information
For step...
Information on...
Is available in...
All
options for setup and operation of
Teradata Administrator
Teradata Administrator User Guide
3
•
•
•
•
• SQL Data Definition Language Syntax
and Examples
• SQL Data Definition Language Detailed
Topics
CREATE DATABASE
DELETE DATABASE
DROP DATABASE
MODIFY DATABASE
an overview of SQL procedures and how
they are stored in the database
104
SQL Stored Procedures and Embedded SQL
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Databases
Working with Table Access Privileges for Views
You must grant table access privileges to all views databases to allow the views within each
database to access tables in the Tables database.
Note: When table access privileges are granted to a Views database, the individual views
inherit the right to access tables in the Tables database from the parent Views database.
Granting Table Access to Each Views Database
1
Start Teradata Administrator and log on as user DBADMIN.
2
On the main screen, click the Preview Mode button
SQL.
3
Click Tools>Grant/Revoke>Object Rights.
4
In the Grant/Revoke Objects dialog:
to allow display of generated
a
From the Database Name drop-down menu, select the Tables database. This is the
object the privileges are granted on.
b
From the Object Type drop-down menu, select Database.
c
Click the To/From User tab and select a Views database. The privileges are granted to
this object.
d
In the Normal field, check the following to select the privileges being granted:
•
For read-only views: Check Select.
•
For updatable views: Check Select, Insert, Update, and Delete.
e
Check the Grant box in the lower right-hand corner of the screen to give the database
the privilege of extending the defined privileges to other databases. This specifies the
WITH GRANT OPTION clause.
f
Click the Grant button. The Query Window displays the generated GRANT statement,
for example:
•
For read-only Views databases:
GRANT SELECT ON "Tables_Database" TO "database_name" WITH GRANT
OPTION
•
For the updatable Views databases:
GRANT SELECT, INSERT, UPDATE, DELETE ON "Tables_Database" TO
"database_name" WITH GRANT OPTION
5
g
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
h
Close the Query Window and the Grant/Revoke Objects dialog box.
Log off Teradata Administrator or go on to “About Access Logging” on page 197.
Teradata Data Warehouse Appliance 2690 Implementation Guide
105
Chapter 6: Creating the Database Structure
Working with Tables
Reference Information
For Step...
Information on...
Is available in...
4
syntax and options for the GRANT
(SQL form) statement
SQL Data Control Language
database privileges, including those
conferred by object ownership
Security Administration
Working with Tables
About Teradata Tables
The Teradata CREATE TABLE statement is similar to other ANSI-compliant databases, but
there are differences, so you must convert existing table definitions to Teradata SQL.
The following example shows how a table definition written in Oracle SQL differs from the
same definition written in Teradata SQL. Note that Teradata SQL does not use extents, table
spaces, or storage definitions, and may require changes in data type specifications.
CREATE TABLE statement in Oracle:
CREATE TABLE Table1
( Col1 NUMBER,
Col2 NUMBER,
Col3 NUMBER )
TABLESPACE Tablespace1
STORAGE (INITIAL 6144 NEXT 6144
MINEXTENTS 1 MAXEXTENTS 5 );
The corresponding CREATE TABLE statement in Teradata:
CREATE MULTISET TABLE Table1, FALLBACK,
NO BEFORE JOURNAL,
NO AFTER JOURNAL
(Col1 INTEGER,
Col2 INTEGER,
Col3 INTEGER)
PRIMARY INDEX (Col1);
For more about CREATE TABLE, see “Creating Tables” on page 112.
To ensure data integrity and system security, consider the following general rules when
implementing tables:
106
•
Create individual tables in the Tables_Database.
•
Set privileges so that general users cannot directly access or modify the data tables. Provide
general user access to table data using views and macros.
•
Provide direct table access only to designated administrative users who perform updates to
the table definitions or table data.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
Table Implementation Overview
1
Using the example provided, become familiar with Teradata table structure and how it
may differ from table structure in your current database. See “About Teradata Tables” on
page 106.
2
Convert the table definitions for your existing database into Teradata table definitions. See
“Converting Existing Database Tables to Teradata Tables” on page 107.
3
Become familiar with primary index concepts and requirements. See “About Primary
Indexes” on page 109.
4
Define the primary index for each table. See “About Primary Indexes” on page 109.
5
Generate tables using the CREATE TABLE statement. See “Creating Tables” on page 112.
6
After creating and populating a table, monitor perm skew to assess whether the primary
index requires modification. See “Validating Primary Index Selection” on page 117.
Converting Existing Database Tables to Teradata Tables
This procedure uses Oracle as an example to show how you might convert tables created in an
ANSI-compliant database to Teradata.
1
Identify each Oracle schema/user and all database objects (for example, tables, indexes,
views, and materialized views) contained in each schema.
Oracle uses schemas to group database objects into functional groupings that are created
and owned by users.
In Teradata, database objects are created and organized within the owning database or
user:
•
A database is a collection of related database objects. A database also contains an
allotment of space from which users can create and maintain their own objects, or
other users or databases.
•
A user is similar to a database, having a space allocation and the capacity to contain
objects. However, a user also has a password and can log on to the system, whereas a
database cannot.
2
Identify the schemas that have objects you want to migrate to Teradata.
3
Create Teradata databases that correspond to the Oracle schemas and map the schemas to
the corresponding Teradata databases.
4
Identify the DDL for each schema object.
5
Map Oracle data types to Teradata data types. See “About Teradata Data Types” on
page 283.
6
Map Oracle table elements to Teradata table elements. See “Creating Tables” on page 112
for a description of common Teradata table options.
Oracle and Teradata tables have some common elements:
•
All tables have names.
•
All tables contain columns with data types.
•
Tables can be partitioned.
Teradata Data Warehouse Appliance 2690 Implementation Guide
107
Chapter 6: Creating the Database Structure
Working with Tables
In Oracle, you must create tablespaces to store table data. You can partition a table and
distribute specific partitions for storage in specific tablespaces.
In Teradata, the system uses the Primary Index (PI) to distribute table rows across
units of parallel execution (AMPs). See “Choosing a Primary Index” on page 111.
You can achieve further partitioning of the data rows within each AMP by defining a
Partitioned Primary Index (PPI) for the table, which is similar to the type of
partitioning that Oracle tables perform. However, it is easier to define PPI schemes in
Teradata because the partitioning is a logical organization of data within the database
file system, and it requires no knowledge of table space definitions or physical disks.
For more information, and “Partitioned Primary Indexes” on page 109.
•
Constraints can be defined on table columns.
•
Referential integrity can be defined.
•
Global temporary tables are supported.
•
The data block size can be defined to optimize the storage of row data.
•
Freespace can be defined to retain room after loading for future data growth.
•
Triggers can be defined. See “Triggers” on page 294.
Teradata has a number of additional table options, including:
•
Primary index - used for data distribution, data access, table joins, and aggregations.
For details, see “About Primary Indexes” on page 109.
•
FALLBACK option - allows mirroring of table data for recovery scenarios.
•
Journaling options - stores an image of each data row that has been changed to provide
data protection in case of a failure.
Also, in Oracle you must enable a table to be accessed with parallel query processes,
whereas parallel query process are automatically accepted in Teradata.
7
Translate the DDL for each schema object to Teradata DDL.
The DDL for creating tables differs between Oracle and Teradata primarily in how space
utilization is defined for the tables.
In Oracle, database objects are created and stored in tablespaces. Tables can have space
utilization parameters describing how they will use space in tablespaces.
In Teradata, database objects are created and stored in databases or users. The database or
user definition also defines a space allocation. See “Working with Databases” on page 99.
The system automatically transfers space from a database or user to owned tables as
needed, so Teradata table definitions do not include database storage management clauses.
Recommendation: To facilitate loading data from your Oracle table into the new Teradata
table, define the column names of the Teradata table to be the same as the column names
of your Oracle table. You may use the ALTER TABLE statement to rename any of the
columns in the Teradata table after loading the data into the table.
For details on using the CREATE TABLE statement, see “Creating Tables” on page 112.
108
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
About Primary Indexes
Defining the primary index (PI) for a table is the most critical aspect of table design.
The system uses the PI to assign each data row to an Access Module Processor (AMP). A well
chosen PI balances the distribution across AMPs and helps optimize the performance of
queries that access the table. PIs also enable efficient joins and aggregations.
Note: A Teradata Database query does not use a PI for access unless all columns in the index
are in an equality predicate or an IN LIST.
After you identify the PI requirements for a table you must specify the PI, and whether it is
unique, as part of the CREATE TABLE statement.
No Primary Index (NoPI) Tables
You can create tables without a primary index (NoPI). The performance of FastLoad and
Teradata Parallel Data Pump (TPump) Array INSERT operations can be enhanced by using
NoPI staging tables.
You can use NoPI tables as intermediate work tables where PI access is not a consideration.
The system automatically balances the distribution of NoPI tables across AMPs.
NoPI tables are designed for temporary use. In all other circumstances, Teradata recommends
that you specify a primary index when you create a table.
Unique and Nonunique Primary Indexes
You can define the primary index as unique (UPI) or nonunique (NUPI), depending on
whether duplicate values are allowed in the indexed column set.
UPIs provide optimal data distribution and are typically assigned to the primary key for a
table. However, the primary key is not necessarily always the best candidate for a primary
index. For a comparison of primary keys and primary indexes, see “How PIs Relate to Primary
Keys and Foreign Keys” on page 110.
When a table is designed with a NUPI, consider assigning a uniqueness constraint such as
PRIMARY KEY or UNIQUE to the primary or other alternate key of the table. This both
enforces uniqueness and enhances retrieval for applications where the primary or other
alternate key is frequently used as a selection or join criterion.
Partitioned Primary Indexes
Primary indexes can be partitioned or nonpartitioned. A partitioned primary index (PPI)
permits rows to be assigned to user-defined data partitions on the AMPs. A PPI is defined to
be either single-level or multilevel. Multilevel partitioning allows each partition to be
subpartitioned.
The greatest potential gain in partitioning a primary index is the ability to access only the rows
of the qualified partitions while skipping partitions that do not contain rows meeting the
search conditions of a query.
A PPI increases query efficiency by avoiding full table scans without the overhead and
maintenance costs of secondary indexes. A multilevel PPI provides multiple access paths to the
Teradata Data Warehouse Appliance 2690 Implementation Guide
109
Chapter 6: Creating the Database Structure
Working with Tables
rows in the base table and can improve query performance through partition elimination at
each of the various levels or combination of levels.
PPIs are designed to optimize range queries while also providing efficient PI join strategies. A
range query requests data that falls within specified boundaries. A common example of this is
queries that involve date ranges.
Recommendation: Consider defining a table with a PPI to support either of the following
workload characteristics:
•
A majority of the queries in the workload specify range predicates on some column,
particularly a date column, of the PPI table.
•
A majority of the queries in the workload specify an equality predicate on some column of
the PPI table, and that column is either:
•
Not the only column in the primary index column set
or
•
Not a primary index column
How PIs Relate to Primary Keys and Foreign Keys
A primary key defines a column, or columns, that uniquely identify a row in a table. The
values defining a primary key for a table:
•
Must be unique
•
Should not change
•
Cannot be null
The following table summarizes the differences between logical primary keys and physical
primary indexes:
Primary Key
Primary Index
Important element of logical data model.
Not used in logical data model.
Used to maintain referential integrity.
Used to distribute and retrieve data.
Must be unique to identify each row.
Can be unique or nonunique.
Values should not be changed if you want to
maintain data integrity and preserve historical
relations among tables.
Values can change.
Cannot be null.
Can be null.
Does not imply access path.
Defines the most common access path.
Required by Teradata Database only if
referential integrity checks are to be performed.
Defined for most production tables. (Some
staging tables may not have a primary index.)
Teradata Database uses a unique primary or secondary index to enforce a primary key;
therefore, the primary key can affect how Teradata Database distributes and retrieves rows.
110
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
Although the primary key is often used as the primary index for a table, it may or may not be
the best column set to choose as a primary index. You should base your primary index
decision on physical database design considerations that may favor columns other than those
of the primary key.
A foreign key identifies table relationships. They model the relationship between data values
across tables. A foreign key defines a column, or combination of columns, in a table. The
foreign key column(s) must exist in the referenced tables as a primary key or a UNIQUE
alternate key.
Teradata Database uses primary and foreign keys to maintain referential integrity between
tables. Foreign keys are also used in join conditions.
Choosing a Primary Index
There are three essential factors to consider when choosing a PI:
•
Uniform data distribution (the most important consideration)
•
Optimal access to the data
•
The volatility of indexed column values
Use the following guidelines for selecting columns to be used as primary indexes:
•
Select columns that consist mainly of unique, distinct values.
This is the most important consideration. Columns with distinct values distribute data
rows evenly across all AMPs in the configuration. This maximizes parallel processing by
allowing all the processors to participate in processing the data rows for a request.
Avoid using columns with a small number of distinct values that are repeated frequently or
columns that have many nulls. This will cause uneven distribution of data rows resulting
in some AMPs having more rows to process than others, and will increase the potential for
performance bottlenecks.
Recommendation: Select columns having significantly more distinct values than the
number of AMPs in the configuration.
•
Select columns that are most frequently used in equality predicate conditions.
•
Select columns that are most frequently used to access rows.
The PI provides the most efficient method to access data in a table. Therefore, choosing
the PI on the most frequently used access path provides for optimal data access. For
example, if the table is frequently joined with a specific set of tables, consider defining the
PI on the column set that is typically used as the join condition.
Equality conditions permit direct access to the row. Inequality conditions require
additional processing.
•
Select columns that do not have any of the following data types: BLOB, CLOB, Period,
UDT, ST_Geometry, MBR.
•
Choose as few columns as possible for the PI to optimize its generality.
•
Select primary indexes so that query plans use AMP-local processing and avoid row
redistributions.
Teradata Data Warehouse Appliance 2690 Implementation Guide
111
Chapter 6: Creating the Database Structure
Working with Tables
•
Select columns that are not volatile.
Volatile columns force frequent row redistribution because Teradata Database assigns table
rows to AMPs based on the PI values.
Note: Several DBSControl values, including those for AMP buffer size, affect actual row
distribution.
Recommendation: Select a PI column set that will never be (preferred) or rarely be
updated.
You may encounter conflicts when selecting the optimum primary index for a table. For
example, choosing a PI that gives good distribution of data across the AMPs must be balanced
against choosing a PI that reflects the most common usage pattern of the table. Also, some
applications might favor one type of primary index, while other applications might perform
optimally using a different primary index.
Recommendation: Make even data distribution, not data access patterns, the main priority
when selecting a primary index. Tables and queries change. Access patterns change. However,
data distribution does not. You can always add additional non-primary indexes, such as
secondary and join indexes, to facilitate particular applications. See “Using Indexes to
Improve Query Performance” on page 163 for information on optimizing indexes.
Reference Information
Information on...
Is available in...
indexing:
•
•
•
•
•
•
•
•
primary indexes
partitioned primary indexes
secondary indexes
join indexes (materialized views)
Introduction to Teradata
SQL Fundamentals
Database Design
“Using Indexes to Improve Query Performance” on
page 163
no primary index tables
Database Design.
referential integrity
SQL Fundamentals
Creating Tables
The following procedure shows how to create tables using BTEQ, but you can also use
Teradata Administrator or SQL Assistant. For a comparison of BTEQ and SQL Assistant, see
“Using SQL Assistant to Submit a Query” on page 145.
1
Logon on to Teradata Database as user DBADMIN using BTEQ. See “Starting BTEQ in
Interactive Mode” on page 122.
2
Create one or more tables using the CREATE TABLE statement. For example:
CREATE SET TABLE database_name.table_name, FALLBACK
(column_name data_type,
column_name data_type,
column_name data_type)
UNIQUE PRIMARY INDEX (primary_index_column);
112
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
where:
Syntax Element
Explanation
MULTISET
A MULTISET table allows duplicate rows in compliance with the ANSI
SQL:2008 standard. A SET table does not allow duplicate rows.
SET
If there are uniqueness constraints on any column or set of columns in the table
definition, then the table cannot have duplicate rows even if it is declared as
MULTISET.
database_name
The name of the database where the table will be created if it is different from
the current database.
Recommendation: The database should be the Tables_Database or a database
located within the Tables_Database. See “Working with Databases” on page 99.
If database_name is not specified, the system creates the table in the default
database for the current session.
table_name
The name of the table to be created.
[NO] FALLBACK
Specifies that the system will automatically create a duplicate copy of the
current image of every row in this table to provide backup in case of a failure.
NO FALLBACK is the default.
To specify FALLBACK for all tables in a database, use FALLBACK in the
CREATE DATABASE statement.
Recommendation: Specify FALLBACK for mission-critical tables or tables so
large that their size prevents timely backup to tape or external disk.
column_name
Specifies the name of one or more columns, in the order in which they and
their attributes are to be defined for the table.
Up to 2,048 columns can be defined for a table. Note that other limits or feature
restrictions may apply before you reach the column limit. For example, you can
have no more than 32 large object (LOB) columns per table.
data_type
Specifies a single data type for each column.
Some data types have different names in Teradata than in other databases. For
more information, see “About Teradata Data Types” on page 283.
[UNIQUE]
PRIMARY
INDEX
Specifies the primary index. A table can have no more than one primary index.
If you do not explicitly assign a primary index, Teradata Database will choose a
default primary index (unless you specify NO PRIMARY INDEX).
Recommendation: Explicitly define a PRIMARY INDEX or UNIQUE
PRIMARY INDEX because the default selected by Teradata Database may not
be optimal for the table.
primary_index_
column
Specifies the column(s) that define a primary index. If you specify more than
one column, the index is created on the combined values of each column. You
can specify up to 64 columns.
Recommendation: Choose columns that primarily have unique values, are
frequently accessed, and have values that do not change. See “Choosing a
Primary Index” on page 111.
Teradata Data Warehouse Appliance 2690 Implementation Guide
113
Chapter 6: Creating the Database Structure
Working with Tables
Note: The example is the minimum recommended specification for creating a table. You
can specify additional options, or add them later using the ALTER TABLE statement, see
“Optional Table-level and Column-level Elements” on page 114.
To automate the creation of data tables by using BTEQ scripts, see “Using BTEQ Scripts to
Create Database Objects” on page 123.
3
Set privileges on the table so that only designated administrative users can access the table
directly. See Chapter 10: “Setting Up Users.”
4
Collect statistics on the newly created, empty table. This defines the columns, indexes, and
partitions for a PPI table, as well as the synoptic data structures for subsequent collection
of statistics and demographics. See “Using COLLECT STATISTICS to Optimize Query
Performance” on page 159.
Optional Table-level and Column-level Elements
The following are common optional table-level elements you can specify in the CREATE/
ALTER TABLE statement. For details about these table options and for a complete description
of all table options, see SQL Data Definition Language Syntax and Examples.
Syntax Element
Explanation
GLOBAL
TEMPORARY
Creates a global temporary table. Global temporary tables have a persistent
definition but do not have persistent contents across sessions. Each user
session can materialize up to 2,000 global temporary tables at a time.
JOURNAL
Specifies a Permanent Journal (PJ) for the table, which stores an image of
each data row that has been changed with an INSERT, UPDATE, or DELETE
statement. PJ images can reflect row values as they appeared before the
change, after the change, or both.
To specify a PJ for all tables in a database, use the JOURNAL clauses in the
CREATE DATABASE statement.
Recommendation: Specify journaling for tables that need an additional
level of data protection after you have analyzed data protection needs.
FREESPACE
Specifies the percent of free space that remains on a cylinder during loading
operations. The reserved free space allows table data to expand on current
table cylinders, preventing data migration operations which can impact
system performance. You can control this space at the global and table level.
Recommendation: If little or no table expansion is expected (the table is
read-only), set FREESPACE to 0. Otherwise, choose a percentage that
reflects the growth rate of your table (INSERTs minus DELETEs). Common
settings are 5 to 15%. The maximum allowed is 75%.
DATABLOCKSIZE
Specifies the maximum data block size for blocks that contain multiple
rows. Larger block sizes enhance full table scan operations by selecting more
rows in a single I/O. Smaller block sizes are best for transaction-oriented
tables to minimize overhead by retrieving only what is needed. You can
control the data block size at the global and table level.
Recommendation: Use a larger value if the database is used primarily for
strategic work (decision support/complex queries). Use a smaller value if
the database is used primarily for tactical work (OLTP).
114
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
Syntax Element
Explanation
[UNIQUE] INDEX
Specifies secondary indexes for the table. Secondary indexes (SI) allow quick
access to table data using an alternate, less frequently used path than the
primary index. SIs improve performance by avoiding full table scans. See
“Using Indexes to Improve Query Performance” on page 163.
PARTITION BY
Specifies that the primary index is partitioned based on the value of the
specified partitioning expression. A partitioned primary index (PPI)
permits rows to be assigned to user-defined data partitions, enabling
enhanced performance for range queries while providing efficient PI join
strategies. See “Partitioned Primary Indexes” on page 109.
The following are common optional column-level elements you can specify in the CREATE/
ALTER TABLE statement. For details about these column-level options and for a complete
description of all table options, see SQL Data Definition Language Syntax and Examples.
Syntax Element
Explanation
data_type_attributes
If you specify attributes for a column, you must define its data type before
you define its attributes. The following attributes are supported:
• NOT NULL
• UPPERCASE
• [NOT] CASESPECIFIC
• FORMAT
• TITLE
• NAMED
• DEFAULT or WITH DEFAULT
• CHARACTER SET
• WITH TIME ZONE
Recommendation: Teradata highly recommends that you specify the NOT
NULL attribute for columns that will never be null.
COMPRESS
Specifies a set of distinct values in a column that is to be compressed to zero
space. Column compression can enhance storage capacity, improve
response time for table scans, and reduce disk I/O traffic.
Recommendation: For best results, use multivalue compression where:
• Enough rows contain a compressible value (null, zero, blank, or constant
value) in the compressed field to exceed the break even point.
• The shortened row size eliminates one or more data blocks.
CONSTRAINT
Specifies column-level contraints. The following constraints are supported:
• UNIQUE
• PRIMARY KEY
• FOREIGN KEY
• CHECK
• REFERENCES
Recommendation: Specify a name for the constraint specification.
Teradata Data Warehouse Appliance 2690 Implementation Guide
115
Chapter 6: Creating the Database Structure
Working with Tables
Example CREATE TABLE Statement
This table definition creates the Employee table in the database named Tables_Database:
CREATE SET TABLE Tables_Database.Employee, FALLBACK
(Associate_Id
INTEGER,
Associate_Name
CHAR(25),
Salary
DECIMAL(8,2),
DOB
DATE,
Job_Title
VARCHAR(25),
Dept_No
SMALLINT,
Marital_Status
CHAR,
No_Of_Dependents BYTEINT)
UNIQUE PRIMARY INDEX (Associate_Id);
Using BTEQ script, see “Using BTEQ Scripts to Create Database Objects” on page 123.
See “Loading a Data From an External ODBC Database” on page 266 and “Loading Data from
an External Flat File” on page 271 for sample Teradata Parallel Transporter (PT) load job
scripts that load data into this table.
See “Exporting Data to an External Flat File” on page 275 for a sample Teradata PT export job
script that exports data from this table to an external flat file.
Reference Information
Information on...
Is available in...
an overview of tables, including
global temporary and volatile tables
• SQL Fundamentals
• Database Administration
• syntax, options, and required
privileges for:
• CREATE TABLE
• ALTER TABLE
• DROP TABLE
• RENAME TABLE
SQL Data Definition Language Syntax and Examples
the default database
SQL Fundamentals
data protection using FALLBACK
Database Administration
data types and data type attributes
SQL Data Types and Literals
•
•
•
•
• “About Primary Indexes” on page 109
• “Using Indexes to Improve Query Performance” on
page 163
primary indexes
partitioned primary indexes
secondary indexes
join indexes (materialized views)
using the FREESPACE option to
manage performance, and
guidelines for calculating a
FREESPACE value
116
“FreeSpacePercent” in:
• Database Administration
• Utilities: Volume 1 (A-K)
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Views
Information on...
Is available in...
using the DATABLOCKS option to
manage performance and specifying
a DataBlockSize value
• Database Administration
• Utilities: Volume 1 (A-K)
compressing column values
• “Using Multi-Value Compression (MVC)” on page 218.
column-level and table-level
constraints
Database Design
Validating Primary Index Selection
A well chosen PI balances workload processing evenly among AMPs, leading to parallelism,
efficient data access, and optimal performance. When a PI is poorly chosen, the workload
processing is not balanced (skewed) and performance suffers.
After you create and populate a table, you can use the Teradata Viewpoint Space Usage portlet
to check the PI by monitoring the amount of perm skew (uneven distribution of data) for the
table. See “Identifying and Correcting Space Problems” on page 221.
Note: If a table shows high skew, you can drop the table and recreate it with a new PI.
Working with Views
Database views are created from one or more base tables or from other views. They are virtual
tables that you can use to retrieve data from the underlying views or tables. A view does not
contain data so it does not use any space. Only the view definitions are stored in the Data
Dictionary.
A view may present only a subset of the columns and rows in the base table or tables. In
addition, a column defined in a view can be derived and does not need to exist in the
underlying base tables. For example, you can display summed or averaged data in a view
column.
Views are generally used to:
•
Allow users to access only the rows and columns they need in a table.
•
Enforce security by restricting table access and updates.
•
Provide well-defined, well-tested, high-performance access paths to data.
•
Provide logical data independence, which minimizes the need to modify your applications
if you restructure base tables.
•
Format the output of the data for reports.
•
Specify locking, such as specifying a less restrictive ACCESS lock.
To ensure data integrity and system security, Teradata recommends the following:
•
Set privileges so that general users cannot access or modify data tables directly.
Teradata Data Warehouse Appliance 2690 Implementation Guide
117
Chapter 6: Creating the Database Structure
Working with Views
•
Create views which allow general users to access or modify only the table data they need.
Use views to restrict users to performing specific queries and update functions.
•
Create views in a Views Database. See “Working with Databases” on page 99.
For information on materialized views, see “Join Indexes” on page 168.
Creating Views
You can use the following utilities to create views in Teradata:
•
BTEQ
•
SQL Assistant
BTEQ and SQL Assistant allow you to submit CREATE VIEW DDL statements to Teradata
Database. For a comparison of BTEQ and SQL Assistant, see “Using SQL Assistant to Submit a
Query” on page 145.
The following procedure shows how to create views using BTEQ:
1
Log on to Teradata Database as user DBADMIN using BTEQ. See “Working with the Basic
Teradata Query Utility” on page 122.
2
Create one or more views using the CREATE VIEW statement. For example:
CREATE VIEW database_name.view_name (column_name, column_name) AS
SELECT clause;
where:
Syntax Element
Explanation
database_name
The name of the database where the view will be created if it is different from
the current database.
Recommendation: The database should be a Views Database or a database
located within a Views Database. See “Working with Databases” on page 99.
If database_name is not specified, the system creates the view in the default
database for the current session.
118
view_name
The name of the view to be created.
column_name
The name of a view column. If more than one column is specified, list their
names in the order in which each column is to be displayed for the view.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Views
Syntax Element
Explanation
LOCKING clause
The specified lock is placed on the underlying base table set each time the view
is referenced in an SQL statement.
Recommendation: Create views with a LOCKING FOR ACCESS modifier to
allow concurrent access of the data to read-only users and users who will
modify the data. This prevents deadlocks and increases performance.
ACCESS locking is a tool that can be used to reduce the isolation of a user
request allowing that request to access valid, but uncommitted data that is
subject to change.
This allows users that are interested in a broad, statistical snapshot of the data,
but that do not require precise results, to attain access to data while
modifications to that data are occurring. This can greatly improve
performance, because those users do not have to wait unnecessarily for the
write operation to complete. For more information on the LOCKING clause,
see “Working with Database Locks” on page 153.
SELECT clause
The SELECT statement which obtains the data for the view. The following are
some of the options and clauses you can use:
DISTINCT option
Returns only one row from any set of duplicate rows in the SELECT result.
ALL option
Returns all rows, including duplicate rows in the SELECT result. This is the
default.
TOP n or TOP m PERCENT option [WITH TIES]
Restricts a view to only n rows or m percent of the rows in an underlying base
table. If you do not specify an ORDER BY clause, then a TOP n clause only
specifies that any n base table rows be returned, not the TOP n.
This option provides a fast method to obtain a restricted, non-statistically
random sample of table rows.
FROM clause
Specifies the set of base tables or views from which data for the view are
selected.
WHERE clause
Specifies a conditional expression by which rows for the view are selected.
GROUP BY clause
Groups result rows by the values in one or more columns or by various
extended GROUP BY operations on specified column expressions.
HAVING clause
Specifies a conditional expression by which the groups defined by a GROUP
BY clause are selected.
QUALIFY clause
Specifies a conditional ordered analytical function by which rows for the view
are selected.
Teradata Data Warehouse Appliance 2690 Implementation Guide
119
Chapter 6: Creating the Database Structure
Working with Views
Syntax Element
Explanation
WITH CHECK OPTION clause
Integrity constraint option that restricts the rows in the table that can be
affected by an INSERT or UPDATE statement to those defined by the WHERE
clause. This option only pertains to updatable views.
Recommendation: Specify a WITH CHECK OPTION clause in all your
updatable view definitions to prevent unauthorized modification of data rows.
ORDER BY clause
Specifies the order in which result rows are to be sorted. You can only specify
an ORDER BY clause for a view definition if you also specify either the TOP n
or the TOP m PERCENT option.
Note: The example lists the major options for creating a view. You can modify your view
definition by using the REPLACE VIEW statement.
To automate the creation of views by using BTEQ scripts, see “Using BTEQ Scripts to
Create Database Objects” on page 123.
3
Set privileges on the view as follows:
•
Provide general users read-only access so they can use the view to query data.
•
Provide privileged users read and write access so they can use the view to update data
in the underlying tables.
See Chapter 10: “Setting Up Users,” for information about granting privileges on the view
to users.
Example 1: Creating a View to Limit User Access
The following statement creates a view of the Employee table so that it provides access only to
the names and job titles of the employees in department 300:
CREATE VIEW Views_Database.Dept300 (Associate_Name, Job_Title) AS
SELECT Associate_Name, Job_Title
FROM Tables_Database.Employee
WHERE Dept_No = 300
WITH CHECK OPTION;
The WITH CHECK OPTION prevents using this view to insert a row into the Employee table,
or to update any row of the Employee table where Dept_No is not 300.
Example 2: Creating a View to Generate a Report
The following statement creates a view which calculates the minimum, maximum, and
average salary of each department and displays only those rows with an average salary of
$35,000 or higher.
Because the view definition specifies an ACCESS lock for the table, the view returns valid, but
uncommitted data that is subject to change, particularly if the view selects data at the same
time another user attempts to modify the salary data in the Employee table.
120
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Views
This view is designed for users who need quick access to data, but do not need precise results.
CREATE VIEW Views_Database.Dept_Salary (Dept_No, MinSal, MaxSal, AvgSal)
AS LOCKING TABLE Tables_Database.Employee FOR ACCESS
SELECT Dept_No, MIN(Salary), MAX(Salary), AVG(Salary)
FROM Tables_Database.Employee
GROUP BY Dept_No
HAVING AVG(Salary) >= 35000;
Reference Information
For step...
Information on...
Is available in...
2
overview of views
• SQL Fundamentals
• Data Dictionary
2
• syntax, options, and required
privileges for:
• CREATE VIEW/REPLACE
VIEW
• DROP VIEW
• RENAME VIEW
SQL Data Definition Language Syntax and
Examples
2
the default database
SQL Fundamentals
2
the SELECT statement, including
usage of the options and clauses
SQL Data Manipulation Language
2
• rules for creating, replacing, and
using views
• updatable views
• WITH CHECK OPTION clause
SQL Data Definition Language Syntax and
Examples
2
• deleting rows using views
(DELETE, Basic/Searched Form)
• updating rows using views
(UPDATE)
SQL Data Manipulation Language
2
specifying locking in views
• “Working with Database Locks” on
page 153
• SQL Request and Transaction Processing
2
CREATE RECURSIVE VIEW and
REPLACE RECURSIVE VIEW
SQL Data Definition Language Syntax and
Examples
Teradata Data Warehouse Appliance 2690 Implementation Guide
121
Chapter 6: Creating the Database Structure
Working with the Basic Teradata Query Utility
Working with the Basic Teradata Query Utility
Basic Teradata Query Utility (BTEQ) is a general-purpose, command-based application that
allows users to:
•
Perform administrative tasks, including creation of database objects such as databases,
tables, and views, using SQL DCL, DDL, and DML requests.
•
Format reports for both print and screen output.
You can use BTEQ interactively or you can create and run BTEQ scripts. See “Using BTEQ
Scripts to Create Database Objects” on page 123.
For those familiar with Oracle, BTEQ is similar to SQL*Plus.
Starting BTEQ in Interactive Mode
To start BTEQ on a Windows client and log on to Teradata Database:
1
Click Start>Programs>Teradata Client>Teradata BTEQwin.
2
In the Session Charset Dialog box, select the client character set for your session.
The system will open a BTEQ window with the following BTEQ prompt:
Enter your logon or BTEQ command:
3
Log on to Teradata Database.
.LOGON tdpid/userid
where:
•
tdpid is the name by which the Teradata Data Warehouse Appliance 2690 is known to
the network.
•
userid is the user id of the user who is logging on.
For example:
.LOGON tdat1/DBADMIN
4
Submit the password associated with userid when prompted. If the logon is successful, the
system will display:
•
The Teradata Database release and version.
•
The transaction semantics for the session.
•
The character set for the session.
•
The following BTEQ prompt:
BTEQ -- Enter your DBC/SQL request or BTEQ command:
5
A successful logon establishes a BTEQ session on the Teradata Database system. At this
point, you can enter your SQL request or BTEQ command.
To log off Teradata Database or exit BTEQ, enter one of the following commands:
122
•
.LOGOFF - ends the current Teradata Database sessions without exiting BTEQ.
•
.EXIT or .QUIT - ends the current Teradata Database sessions and exits BTEQ or exits
BTEQ if you are not logged on to Teradata Database.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 6: Creating the Database Structure
Working with the Basic Teradata Query Utility
Reference Information
For step...
Information on...
Is available in...
All
options for setup and operation of
BTEQ
Basic Teradata Query Reference
5
session transaction semantics
“About Session Modes and Transaction
Processing” on page 142.
Using BTEQ Scripts to Create Database Objects
You can automate the creation of tables, views, and other database objects using BTEQ scripts.
The following example procedure uses a BTEQ script to create the sample table from
“Working with Tables” on page 106.
1
Create a text file named Create_Emp_Table.sql with the following contents:
.LOGON tdpid/UserName,Password
CREATE SET TABLE Tables_Database.Employee, FALLBACK
(Associate_Id INTEGER,
Associate_Name CHAR(25),
Salary DECIMAL(8,2),
DOB DATE,
Job_Title VARCHAR(25),
Dept_No SMALLINT,
Marital_Status CHAR,
No_Of_Dependents BYTEINT)
UNIQUE PRIMARY INDEX (Associate_Id);
.quit
where:
2
•
tdpid is the name by which the Teradata Data Warehouse Appliance 2690 is known to
the network.
•
UserName is the name used to log on to Teradata, such as DBADMIN.
•
Password is the password associated with UserName.
Create a batch file named Create_Emp.bat with the following contents:
bteq < Create_Emp_Table.sql > Create_Emp_Table.log 2>&1
where:
2>&1
redirects the error messages to Create_Emp_Table.log to be printed along with the output
messages.
3
Place Create_Emp.bat and Create_Emp_Table.sql in the same folder.
4
Execute Create_Emp.bat to create the Employee table in the database, Tables_Database.
Create_Emp.bat invokes BTEQ using Create_Emp_Table.sql as the input file. BTEQ executes
the commands and statements in the Create_Emp_Table.sql file and writes its output and any
errors to the Create_Emp_Table.log file.
Teradata Data Warehouse Appliance 2690 Implementation Guide
123
Chapter 6: Creating the Database Structure
Checkpoint
Reference Information
Information on...
Is available in...
starting and exiting BTEQ
“Working with the Basic Teradata Query Utility” on
page 122.
running batch jobs to submit BTEQ
commands and Teradata SQL
Basic Teradata Query Reference
Checkpoint
Before leaving Chapter 6: “Creating the Database Structure,” make sure that:
√
Result
Reference
You have the following databases:
“Working with Databases” on page 99.
• Tables, which contains all data tables
• Views, which contains all views and macros
• Your pre-existing ANSI-compliant tables are
converted to Teradata and are empty,
awaiting data loading.
• You have new tables created in Teradata that
have a primary index.
“Working with Tables” on page 106.
You have views created in the Views database.
“Working with Views” on page 117.
If you do not have these results, return to the section in the Reference column and review that
procedure.
124
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 7
Converting Queries to Teradata
SQL
When converting existing SQL queries to Teradata SQL, you must to address the differences
between your existing database and Teradata Database. The topics in this chapter show some
of the main differences, using conversion from Oracle as an example. Conversions from other
databases involve similar considerations.
Always test converted queries thoroughly before moving them to a production environment.
Compare the query results in your current system to the query results in Teradata Database to
verify that the converted queries run as expected.
Recommendation: You can convert existing SQL as written and translate it directly to
Teradata SQL. However, this approach may not fully use the benefits that Teradata provides.
The best approach for some query types may be to migrate your business rules and logical
framework into Teradata and then create new queries that are optimized for the Teradata
Database environment.
Query Conversion Overview
When converting existing queries to Teradata SQL, make sure to consider the requirements in
each of the following topics:
•
“Converting Data Types to Teradata Data Types” on page 126.
•
“Converting Built-in SQL Functions” on page 126
•
“Converting Hierarchical Joins” on page 129
•
“Converting Outer Joins” on page 130
•
“Checking the Use of NULLs in Queries” on page 131
•
“Converting Nested Aggregate Operations” on page 131
•
“Converting External Tables to Table Functions” on page 132
•
“Converting Queue Tables” on page 132
•
“Converting Queries to Set Processing” on page 133
•
“Converting PL/SQL Functions” on page 135
•
“General Considerations for Using Teradata SQL” on page 136
Teradata Data Warehouse Appliance 2690 Implementation Guide
125
Chapter 7: Converting Queries to Teradata SQL
Converting Data Types to Teradata Data Types
Converting Data Types to Teradata Data Types
Some data types supported in your current database may function the same in Teradata
Database, while other data types must be converted to Teradata data types. For details, see
“About Teradata Data Types” on page 283.
Also, be aware of possible differences in the rules for converting data from one type to another,
especially in the case of implicit data type conversions.
Teradata Database permits the assignment and comparison of some types without requiring
the types to be explicitly converted. Teradata also performs implicit type conversions on some
argument types (for example, SQRT) passed to macros, procedures, and SQL functions.
You can explicitly convert one data type to another using the CAST function. For example:
CAST (expression AS ansi_sql_data_type|data_definition_list)
where:
Syntax Element
Explanation
expression
An expression with known data type to be converted to a different data type.
ansi_sql_data_type
The new data type for expression.
data_definition_list
The new data type or data attributes or both for expression.
Reference Information
Information on...
Is available in...
Teradata data types
• “About Teradata Data Types” on page 283
• SQL Data Types and Literals
data type conversions
“Data Type Conversions” in SQL Functions,
Operators, Expressions, and Predicates
Converting Built-in SQL Functions
Oracle SQL includes a collection of data manipulation functions, some of which are uniquely
required by Oracle to support its ability to compare stored data to literal values, or to convert
external data values to a data type that Oracle may store. Some Oracle SQL functions may be
directly translated to the equivalent Teradata SQL function, but others may not.
If you use built-in SQL functions that are specific for your database, you must convert those
functions so that they can be used in Teradata. You have the following options:
•
126
Replace the built-in function with an equivalent Teradata SQL function. See “About
Oracle-Equivalent Teradata UDFs” on page 127.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Converting Built-in SQL Functions
•
Translate the function into Teradata SQL and incorporate it into a converted SQL query or
save it as a procedure (in Teradata, referred to as a stored procedure). See “Translating
Built-in SQL Functions to Teradata SQL” on page 128.
•
Create a new Teradata user-defined function (UDF) that provides the same functionality
as the existing built-in function. See “Reference Information” on page 130 for a list of
documents with information about UDF creation and use.
About Oracle-Equivalent Teradata UDFs
The Teradata Developer Exchange provides user-defined functions (UDFs) that emulate the
most commonly used Oracle built-in SQL functions, including:
•
•
•
•
•
•
•
•
ADD_MONTHS
ASCII
BITAND
CEIL
CHR
DECODE
FLOOR
GREATEST
•
•
•
•
•
•
•
•
GREPC
INITCAP
INSTR
LAST_DAY
LEAST
LENGTH
LPAD
LTRIM
•
•
•
•
•
•
•
•
MONTHS_BETWEEN
NVL
REPLACE
ROUND
ROUND_TEST
RPAD
RTRIM
SIGN
•
•
•
•
•
•
TO_CHAR
TO_DATE
TO_NUMBER
TRANSLATE
TRUNC
UNICODE
After you install these UDFs, when Teradata Database encounters a call to an Oracle built-in
SQL function, it invokes the corresponding UDF to process the function call.
For additional information on Teradata UDFs, see “User-Defined Functions” on page 293
Installing Oracle-Equivalent Teradata UDFs
1
Verify that your Teradata system has a C or C++ compiler on the node used to compile the
UDFs.
2
Go to the Teradata Developer Exchange at: http://developer.teradata.comand use the
search function to find “Teradata UDFs for Popular Oracle Functions.”
3
Download the UDFs (oraudfs_v_4.zip).
4
Open oraudfs_v_4.zip and extract the files, specifying the folder where you want the files
extracted and selecting the option to extract the files using folder names.
5
Open the extracted ReadMe.txt file and follow the instructions to install the UDFs.
Make sure the default database for the session is the database in which you want the UDFs
installed. Teradata Database provides a public database called SYSLIB for installing global
functions.
IMPORTANT: Teradata provides these UDFs only for customer convenience. Although
the UDFs are proven to work in many situations, Teradata does not support the UDFs,
does not guarantee that the UDFs will work in all environments, and assumes no
responsibility if the UDFs do not produce the expected results. Customers who implement
the UDFs are responsible for testing UDF results against the corresponding Oracle
function results to ensure that the UDFs work as expected.
Teradata Data Warehouse Appliance 2690 Implementation Guide
127
Chapter 7: Converting Queries to Teradata SQL
Converting Built-in SQL Functions
Using Oracle-Equivalent Teradata UDFs
1
Grant users who invoke the UDFs the EXECUTE FUNCTION privilege on the functions
or on the database containing the functions. For example, if you installed the UDFs in the
SYSLIB database, the following SQL statement provides user blink with privileges to
invoke the UDFs:
GRANT EXECUTE FUNCTION ON SYSLIB TO blink;
2
Use the UDFs anywhere you would use the corresponding Oracle built-in SQL functions.
Each subfolder that was created when you extracted the ZIP file contains a .btq file that
provides an example of how to use a particular UDF.
Translating Built-in SQL Functions to Teradata SQL
If you do not want to use the Teradata UDFs for Oracle, you can rewrite the Oracle built-in
functions using Teradata SQL and Teradata built-in functions. The following table shows how
some of the Oracle functions can be translated to Teradata SQL.
Oracle
Teradata
DECODE(a,b,c,d)
CASE a WHEN b THEN c ELSE d END
GREATEST(a,b)
CASE WHEN a >= b THEN a ELSE b END
LEAST(a,b)
CASE WHEN a <= b THEN a ELSE b END
SIGN(a)
CASE a WHEN > 0 THEN 1
WHEN < 0 THEN -1
ELSE 0 END
NVL(a,b)
COALESCE(a, b)
or
ZEROIFNULL(n)
128
INSTR(s,c)
INDEX(s,c)
LENGTH(s)
CHAR_LENGTH(s)
LPAD(a,n)
CAST (a AS CHAR(n) )
LTRIM(a,c)
TRIM (LEADING c FROM a)
LTRIM(RTRIM(a,c))
TRIM (BOTH c FROM a)
RTRIM(a,c)
TRIM (TRAILING c FROM a)
TO_CHAR(x[, f])
CAST (x AS CHAR(n) [FORMAT 'f'] )
TO_DATE(x[, f])
CAST (x AS DATE|TIMESTAMP [FORMAT 'f'] )
TO_NUM(BER)(x[, f])
CAST (x AS NUMERIC(n,m) [FORMAT 'f'] )
TRUNC
CAST (x AS DATE FORMAT 'f')
MONTHS_BETWEEN(d,e)
ABS (CAST ((d - e) MONTH(4) AS INTEGER))
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Converting Hierarchical Joins
Reference Information
Information on...
Is available in...
UDFs
“User-Defined Functions” on page 293.
Procedures and external procedures
“About Procedures and External Procedures” on
page 291.
Supported functions in Teradata Database
SQL Functions, Operators, Expressions, and Predicates
Teradata built-in functions
CASE and COALESCE expressions
• using ZEROIFNULL to convert data
from null to 0
• using ABS to compute the absolute
value of an argument
TRIM and INDEX string functions
using CHAR_LENGTH to get the length of
a string either in logical characters or in
bytes
explicit data type conversions using CAST
using the FORMAT phrase to control the
display of expressions, column data, and
conversions between data types
Converting Hierarchical Joins
Teradata supports hierarchical queries, but the syntax for coding hierarchical queries in
Teradata may differ from the syntax used in your current database. Therefore, you may need
to rewrite existing hierarchical queries using Teradata syntax.
The following example shows an Oracle hierarchical query. This query returns the employee
IDs of the people who work for the manager whose employee ID is 801. The results returned
include all the employees that work directly for employee 801, as well as all the people that
work within the management hierarchy of the organization that employee 801 belongs to.
SELECT Employee_Id FROM
( SELECT Employee_Id FROM Employee
start with Employee_id = 801
connect by prior Employee_Id = Manager_Id
)
WHERE Employee_Id ^= 801
ORDER BY Employee_Id;
You can create the same query in Teradata as follows:
WITH RECURSIVE Temp_Table (Employee_Number) AS
( SELECT Root.Employee_Number
Teradata Data Warehouse Appliance 2690 Implementation Guide
129
Chapter 7: Converting Queries to Teradata SQL
Converting Outer Joins
FROM Employee Root
WHERE Root.Manager_Employee_Number = 801
UNION ALL
SELECT Indirect.Employee_Number
FROM Temp_Table Direct, Employee Indirect
WHERE Direct.Employee_Number = Indirect.Manager_Employee_Number
)
SELECT * FROM Temp_Table ORDER BY Employee_Number;
Reference Information
Information on...
Is available in...
the concept of recursive queries
SQL Fundamentals
use of the WITH [RECURSIVE] Request
Modifier in a query
SQL Data Manipulation Language
Converting Outer Joins
Teradata supports Left, Right, and Full outer joins, but the syntax for coding outer joins in
Teradata SQL may differ from the syntax used in querying your current database. Therefore,
you may have to rewrite your outer joins using the Teradata SQL syntax.
The following example shows the outer join syntax for Teradata. This is also the standard,
suggested outer join syntax for Oracle.
The query returns a sorted report of department IDs and names of employees that work in
those departments. All employees appear in the returned list. If the Dept_ID of an employee is
not present in the Department table, then the Dept_ID shown for that employee is null.
SELECT A.Dept_ID, B.Name
FROM Department A LEFT OUTER JOIN Employee B
ON A.Dept_ID = B.Dept_ID
ORDER BY A.Dept_ID, B.Name;
Oracle also supports this older outer join syntax, which is not supported in Teradata:
SELECT A.Dept_ID, B.Name
FROM Department A, Employee B
WHERE A.Dept_ID = B.Dept_ID(+)
ORDER BY A.Dept_ID, B.Name;
Queries written using this old outer join syntax must be rewritten to use the Teradata syntax.
Reference Information
130
Information on...
Is available in...
outer joins
SQL Data Manipulation Language
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Checking the Use of NULLs in Queries
Checking the Use of NULLs in Queries
In Teradata Database, the keyword NULL is not the same as an empty string. A null is a place
holder indicating that no value is present. An empty string (' ') is a real value.
For example, given the following statements:
INSERT INTO String_Table VALUES ('', 'TestString');
INSERT INTO String_Table VALUES (NULL, 'TestString');
SELECT Column1, Column2 FROM String_Table;
In Oracle, the output from the SELECT statement is:
Column1
------?
?
Column2
------TestString
TestString
where '?' is the default value displayed for a null by the application that executed the query.
Note that the empty string is interpreted as a null in Oracle.
In Teradata Database, the output from the SELECT statement (using SQL Assistant) displays
an empty string corresponding to the first INSERT statement, and a null for the second
INSERT statement.
Column1
------?
Column2
------TestString
TestString
Reference Information
Information on...
Is available in...
nulls
SQL Fundamentals
character string literals
SQL Data Types and Literals
Converting Nested Aggregate Operations
Aggregate operations cannot be nested in Teradata Database.
For example, in Oracle, the following is valid:
SELECT MIN(SUM(…))
In Teradata, you must use syntax such as:
SELECT MIN(T.C) FROM (SELECT SUM(…)) as T(C);
Teradata Data Warehouse Appliance 2690 Implementation Guide
131
Chapter 7: Converting Queries to Teradata SQL
Converting External Tables to Table Functions
Aggregates can be nested in aggregate window functions. The following statement is valid in
Teradata Database and includes an aggregate SUM function nested in a RANK window
function:
SELECT region
,product
,SUM(amount)
,RANK() OVER (PARTITION BY region ORDER by SUM (amount))
FROM table;
Reference Information
Information on...
Is available in...
aggregates
SQL Functions, Operators, Expressions, and Predicates
aggregate window functions
SQL Functions, Operators, Expressions, and Predicates
Converting External Tables to Table Functions
Oracle External Tables must be converted to Table Functions in Teradata Database. A table
function is a type of UDF, which is invoked in the FROM clause of an SQL SELECT statement
and which returns a table a row at a time in a loop to the SELECT statement. The function can
produce the rows of a table from the input arguments passed to it or by reading an external file
or message queue.
The number of columns in the rows that a table function returns can be specified dynamically
at runtime in the SELECT statement that invokes the table function.
Reference Information
Information on...
Is available in...
UDFs
“User-Defined Functions” on page 293.
Converting Queue Tables
The queue tables supported in non-Teradata databases often have similar functionality to
Teradata queue tables, but there may be differences in the way the tables are created and
manipulated. For example, Teradata queue tables are created using DDL and manipulated
using SQL. Oracle queue tables are created and manipulated using PL/SQL, JMS, and Oracle
APIs.
You must translate existing queue table requirements and management into Teradata queue
tables and processes.
132
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Converting Queries to Set Processing
Reference Information
Information on...
Is available in...
syntax and options for CREATE TABLE
(Queue Table Form)
SQL Data Definition Language Syntax and Examples
strategy for using queue tables
SQL Data Definition Language Detailed Topics
manipulating data in queue tables using:
SQL Data Manipulation Language
•
•
•
•
INSERT (push)
SELECT AND CONSUME (pop)
SELECT (peek)
DELETE, UPDATE, or MERGE
Converting Queries to Set Processing
For non-Teradata database systems, business processes often are broken into multiple, simple
SQL queries that use sequential, row-at-a-time, cursor processing. Although coding this type
of SQL query is easier, it may not be the most efficient processing method.
Teradata Database uses parallel architecture and set processing to simultaneously update sets
of rows, which is not possible using row-at-a-time cursor processing.
When migrating queries to Teradata or developing new queries, use SQL constructs that take
advantage of Teradata parallel processing.
Instead of using...
Use...
IF statements
CASE operations or predicates
nested loops
joins
nested procedures or functions
joins or subqueries
Example 1 Conditional Insert
The following example uses a cursor to insert data into the Depositors table. The INSERTs are
processed one row at a time.
cursor A is SELECT Acct, Name, Amt FROM Deposits;
FOR A_Rec IN A LOOP BEGIN
IF A_Rec.Amt > 0 THEN
IF A_Rec.Name = ' ' THEN A_Rec.Name = ‘UNKNOWN’;
END IF;
INSERT INTO Depositors (Account, Name) VALUES
(A_Rec.Acct, A_Rec.Name);
END IF;
END;
Teradata Data Warehouse Appliance 2690 Implementation Guide
133
Chapter 7: Converting Queries to Teradata SQL
Converting Queries to Set Processing
The SQL in the previous example can be rewritten using a CASE statement. CASE expressions
help increase performance by returning multiple results in a single pass over the data rather
than making multiple passes over the data.
INSERT INTO Depositors (Account, Name)
SELECT A.Acct, CASE A.Name
WHEN ' '
THEN ‘UNKNOWN’
ELSE A.Name
END
FROM Deposits A
WHERE A.Amt > 0;
Example 2 IF… ELSIF… ELSE
The following example uses a FOR loop and an IF...ELSIF...ELSE statement to set the value for
GL_Acct. This serial operation INSERTs data into the Gen_Ledger table one row at a time.
cursor Dep is SELECT Amt, D_date, AcctNum FROM Deposits;
BEGIN
FOR Deposits_Rec IN Dep LOOP BEGIN
acct_num := Deposits_Rec.AcctNum;
IF acct_num = '999999990' THEN
GL_Acct := 'SLUSH';
ELSIF acct_num = '999999991' THEN
GL_Acct := 'MY SWISS BANK ACCT';
ELSIF acct_num = '999999992' THEN
GL_Acct := 'BLDG FUND';
ELSE
GL_Acct := 'CUST DEPOSIT';
END IF;
INSERT INTO Gen_Ledger (Amount, Acct, DDate)
VALUES (Deposits_rec.Amt, GL_Acct, Deposits_rec.D_date);
END LOOP;
END;
You can rewrite the SQL using a CASE statement, which simultaneously processes multiple
rows.
INSERT INTO Gen_Ledger (Amount, Acct, DDate)
SELECT
DEP.Amt
,CASE WHEN DEP.AcctNum = '999999990' THEN 'SLUSH'
WHEN DEP.AcctNum = '999999991' THEN 'MY SWISS BANK ACCT'
WHEN DEP.AcctNum = '999999992' THEN 'BLDG FUND'
ELSE 'CUST DEPOSIT'
END
,DEP.D_date
FROM Deposits DEP;
Example 3 Nested Loop
The following Oracle SQL uses a nested FOR loop to update the Accts table. This serial
operation cycles through the loops one row at a time.
acct_bal NUMBER(9,2);
acct_num CHAR(9);
cursor TXN_CUR is SELECT Amt, AcctNum
134
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Converting PL/SQL Functions
FROM Acct_Transactions
WHERE AcctNum = acct_num;
cursor ACCT_CUR is SELECT AcctNum, acct_balance FROM Accts;
BEGIN
FOR acct_rec IN ACCT_CUR LOOP BEGIN
acct_num := acct_rec.AcctNum;
acct_bal := acct_rec.acct_balance;
FOR txn_rec IN TXN_CUR LOOP BEGIN
acct_bal := acct_bal + txn_rec.Amt;
END LOOP;
UPDATE Accts SET acct_balance = acct_bal
WHERE AcctNum = acct_num;
END LOOP;
END;
You can rewrite the SQL using a subquery, which processes multiple rows simultaneously.
UPDATE Accts
SET acct_balance = acct_balance + Txn_Sum.total_amt
FROM ( SELECT AcctNum, SUM(Amt) FROM Acct_Transactions
GROUP BY 2
) Txn_Sum (acct, total_Amt)
WHERE Accts.AcctNum = Txn_Sum.acct
Reference Information
Information on...
Is available in...
CASE expressions
SQL Functions, Operators, Expressions, and Predicates
SQL predicates
SQL Functions, Operators, Expressions, and Predicates
joins
SQL Data Manipulation Language
subqueries
SQL Fundamentals
Converting PL/SQL Functions
Teradata can process complex relational requests in parallel, so it may be possible to convert a
large number of PL/SQL processes to just a few Teradata SQL statements or procedures.
Consolidation of PL/SQL processes into parallel Teradata SQL can result in a reduction in data
processing time, resource usage, and the quantity of code to maintain.
You can migrate Oracle PL/SQL to Teradata by translating it directly to Teradata SQL, and
embedding it into the proper vehicle for query execution. You should also convert the SQL to
Teradata set processing. See “Converting Queries to Set Processing” on page 133.
The following options are available for converting PL/SQL functions for use in Teradata:
•
Translate the function into Teradata SQL and incorporate it into your SQL query.
•
Create a Teradata UDF that provides the same functionality as the PL/SQL function.
•
Translate the function into Teradata SQL and save it as a stored procedure or macro.
Teradata Data Warehouse Appliance 2690 Implementation Guide
135
Chapter 7: Converting Queries to Teradata SQL
General Considerations for Using Teradata SQL
Reference Information
Information on...
Is available in...
set processing
“Converting Queries to Set Processing” on page 133.
UDFs
“User-Defined Functions” on page 293.
Procedures and External Procedures
“About Procedures and External Procedures” on page 291.
creating and using macros
“Working with Macros” on page 149.
General Considerations for Using Teradata SQL
136
•
Teradata does not use a primary index or unique secondary index to process a query unless
all of the indexed columns are in the predicate. Partial index access is supported for join
indexes and for nonunique secondary indexes.
•
Updating or deleting the most current fetched cursor row using the UPDATE/DELETE …
WHERE CURRENT OF statement is valid in ANSI session mode, but not in Teradata
session mode.
•
The COMMIT statement is supported in ANSI session mode only. An error is returned if
the COMMIT statement is issued in Teradata session mode.
•
You cannot close a cursor that is not open. Any attempt to close a cursor that is already
closed results in an error.
•
The result rows from a query are returned in unsorted order unless you specify the
ORDER BY clause. There is no default sequence for result rows.
•
Be aware of Reserved Word differences between your current database and Teradata.
•
Be aware of differences in the rules for naming database objects.
•
Be aware of possible migration issues related to Unicode characters.
•
Convert Oracle SQL*Plus scripts to BTEQ scripts.
•
Convert Oracle SQL*Loader (sqlldr) scripts to Teradata PT job scripts.
•
ODBC considerations:
•
Verify that all ODBC functions in an existing application are supported by Teradata
ODBC.
•
Test all DAO or ADO functions used in both Visual Basic and C++ programs.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Checkpoint
Reference Information
Information on...
Is available in...
indexing
• “About Primary Indexes” on page 109
• “Using Indexes to Improve Query Performance”
on page 163
• updating the most current fetched cursor
row (UPDATE (Positioned Form))
• deleting the most current fetched cursor
row (DELETE (Positioned Form))
• closing an open cursor (CLOSE)
SQL Stored Procedures and Embedded SQL
ANSI session mode and Teradata session
mode
“About Session Modes and Transaction Processing”
on page 142.
COMMIT statement
SQL Data Manipulation Language
ORDER BY clause
Teradata Database reserved words
SQL Fundamentals
naming database objects
Unicode support
International Character Set Support
BTEQ scripts
“Using BTEQ Scripts to Create Database Objects”
on page 123.
Teradata PT job scripts
Chapter 15: “Moving Data To and From Teradata
Database Tables.”
using the ODBC Driver for Teradata with
custom and off-the-shelf ODBC applications
ODBC Driver for Teradata User Guide
Checkpoint
Before leaving Chapter 7: “Converting Queries to Teradata SQL,” make sure that:
√
Result
Reference
Pre-existing data types are converted to Teradata
data types.
“Converting Data Types to Teradata
Data Types” on page 126.
Built-in functions specific to another RDBMS
are converted to Teradata functions.
“Converting Built-in SQL Functions”
on page 126.
Hierarchical queries are rewritten in Teradata
SQL syntax.
“Converting Hierarchical Joins” on
page 129.
Teradata Data Warehouse Appliance 2690 Implementation Guide
137
Chapter 7: Converting Queries to Teradata SQL
Checkpoint
√
Result
Reference
Queries with outer joins are rewritten using
Teradata SQL syntax.
“Converting Outer Joins” on page 130.
You know how the NULLS and empty strings in
your queries will be interpreted in Teradata.
“Checking the Use of NULLs in
Queries” on page 131.
Nested aggregate operations are converted to
Teradata SQL syntax.
“Converting Nested Aggregate
Operations” on page 131.
Oracle external tables are converted to Teradata
Database table functions.
“Converting External Tables to Table
Functions” on page 132.
Queue tables from another RDBMS are
converted into Teradata SQL.
“Converting Queue Tables” on
page 132.
The migrated SQL is taking full advantage of the
parallel processing power of Teradata.
“Converting Queries to Set Processing”
on page 133.
PL/SQL is converted to Teradata SQL and takes
advantage of the parallelism and set processing
features available in Teradata.
“Converting PL/SQL Functions” on
page 135.
You have reviewed and acted upon other SQL
application considerations.
“General Considerations for Using
Teradata SQL” on page 136.
If you do not have these results, return to the section shown in the Reference column and
review that procedure.
138
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 8
Querying the Database
The tasks presented in this chapter, although not specifically required, represent best practices
for using the database. For best results you should read and consider the information
presented. You can perform the tasks that apply to your implementation in any order.
Working with SQL Queries
Invoking SQL Statements
Teradata Database offers the following ways to invoke an executable SQL statement:
•
Interactively from a terminal
•
Embedded within an application program
•
Dynamically created within an embedded application
•
Embedded within an SQL procedure (a procedure that is written using SQL statements)
•
Embedded within an external procedure (a procedure that is written using C, C++, or
Java)
•
Dynamically created within an SQL procedure
•
Submitted in a BTEQ script as a batch job
•
Via a trigger
•
Embedded within a macro
Note: Teradata refers to a procedure as a stored procedure.
Reference Information
Information on...
Is available in...
• SQL procedures (procedures that are
written using SQL statements)
• external procedures (procedures that
are written using C, C++, or Java)
“About Procedures and External Procedures” on
page 291.
embedded SQL
SQL Stored Procedures and Embedded SQL
BTEQ scripts
“Using BTEQ Scripts to Create Database Objects” on
page 123.
triggers
“Triggers” on page 294.
macros
“Working with Macros” on page 149.
Teradata Data Warehouse Appliance 2690 Implementation Guide
139
Chapter 8: Querying the Database
Working with SQL Queries
Using Single and Multistatement Requests
In Teradata Database, a request consists of one or more SQL statements and can span any
number of input lines:
•
A single-statement request is treated as a solitary unit of work.
•
A multistatement request consists of two or more SQL statements that are treated as a
single unit of work. If one statement in the request fails, the entire request fails and the
system rolls back the entire request.
How you specify a multistatement request depends on the application you use to submit the
query.
For example, in BTEQ, a Teradata request terminates with a semicolon (;) character at the end
of a line. A semicolon placed at any other point in the request does not terminate it. You can
use this property to stack multiple SQL statements within a single request either by placing
intermediate semicolons at the beginning of a subsequent line or in the middle of a line.
Example 1 Single-Statement Request in BTEQ
BTEQ submits the following statements to the Teradata Database as three single-statement
requests:
SELECT * FROM Employee;
DELETE FROM Employee
WHERE Associate_Name = 'Winter' AND Associate_Id = 394;
SELECT Associate_Name FROM Employee;
Example 2 Multistatement Request in BTEQ
To submit the three statements in Example 1 as a single multistatement request, enter:
SELECT * FROM Employee
; DELETE FROM Employee
WHERE Associate_Name = 'Winter' AND Associate_Id = 394
; SELECT Associate_Name FROM Employee;
In SQL Assistant, the semicolon position of the request is ignored. You can enter multiple SQL
statements in the Query Window, then use the Execute Parallel command to submit the
statements as a single request. See “Executing Multiple SQL Statements in Parallel” on
page 146.
The multistatement request improves performance for a variety of applications that can
package more than one SQL statement at a time, such as BTEQ, CLI, and the SQL
preprocessor.
Multistatement requests improve system performance by reducing processing overhead. By
performing a series of statements as one request, performance for the client, the Parser, and
the Database Manager are all enhanced.
Because of this reduced overhead, using multistatement requests also decreases response time.
A multistatement request that contains 10 SQL statements could be as much as 10 times more
efficient than the same 10 statements entered as separate requests (depending on the types of
statements submitted).
140
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with SQL Queries
There are a few restrictions on multistatement requests. For example, DDL statements are not
valid in a multistatement request. Multistatement requests are non-ANSI standard.
Reference Information
Information on...
Is available in...
multistatement requests
SQL Fundamentals
submitting single-statement and
multistatement requests using BTEQ
Basic Teradata Query Reference
submitting single-statement and
multistatement requests using SQL
Assistant
• “Using SQL Assistant to Submit a Query” on page 145
• Teradata SQL Assistant for Microsoft Windows User
Guide
About Differences Between Teradata SQL and ANSI SQL
Teradata tries to conform to the ANSI SQL standard whenever possible. However, to create
innovative features and capabilities, Teradata has also developed SQL language elements that
do not conform to the ANSI SQL standard. Often, this was because a standard did not exist
when the feature was designed.
Teradata SQL features conform to industry standards in the following ways:
•
The feature is fully ANSI SQL:2008 compliant
•
The feature is partially ANSI SQL:2008 compliant
•
The feature is a Teradata extension to the ANSI SQL standard
•
The feature is ANSI SQL:2008 compliant, but also has some options or capabilities that are
Teradata extensions to the ANSI SQL standard
•
The feature is ISO SQL/MM Spatial compliant
•
The feature is partially ISO SQL/MM Spatial compliant
In the cases where the existing Teradata SQL dialect differs from the ANSI SQL standard,
Teradata adheres to the following policy:
•
If the difference between the Teradata SQL dialect and the ANSI SQL standard for an SQL
feature is slight, the ANSI SQL is added to the Teradata SQL feature as an option.
•
If the difference between the Teradata SQL dialect and the ANSI SQL standard for an SQL
feature is significant, both syntaxes are offered, and the user has a choice of:
•
using the Teradata SQL dialect by operating in Teradata session mode.
•
using the ANSI SQL standard by operating in ANSI session mode.
Teradata Data Warehouse Appliance 2690 Implementation Guide
141
Chapter 8: Querying the Database
Working with SQL Queries
Reference Information
Information on...
Is available in...
• SQL features available in Teradata, and
which features are ANSI SQL compliant
and which features are Teradata
extensions
• Terminology differences between ANSI
SQL and Teradata
SQL Fundamentals
About Session Modes and Transaction Processing
Teradata Database supports two session modes:
•
ANSI
•
Teradata
In ANSI session mode:
•
Transaction processing follows the rules defined by the ANSI SQL:2008 standard.
•
For Teradata SQL features that support both the ANSI SQL standard syntax and the
Teradata SQL dialect, the ANSI SQL standard syntax is used. See “About Differences
Between Teradata SQL and ANSI SQL” on page 141.
•
The default case specification for character data is CASESPECIFIC.
•
When a character string requires truncation, the excess pad characters are truncated
without reporting an error. Truncation of characters other than trailing nonblank
characters results in a truncation exception.
•
Cursors are always positioned. Updating or deleting the most current fetched cursor row
using the UPDATE/DELETE … WHERE CURRENT OF statement is valid.
•
The default table type is MULTISET, which allows duplicate rows.
•
The TRIM function trims both leading and trailing pad characters by default.
In Teradata session mode:
142
•
Transaction processing follows the rules defined by Teradata before the emergence of the
ANSI SQL standard. These rules largely conform with ANSI semantics, but in some cases
differ in important ways from the ANSI semantics.
•
For Teradata SQL features that support both the ANSI SQL standard syntax and the
Teradata SQL dialect, the Teradata SQL syntax is used. See “About Differences Between
Teradata SQL and ANSI SQL” on page 141.
•
The default case specification for character data is NOT CASESPECIFIC. The exception is
character data of type GRAPHIC, which is always CASESPECIFIC.
•
When a character string requires truncation, the string is truncated silently with no
truncation notification given. This is true for truncation of pad or non-pad characters.
•
Cursors are never positioned. Updating or deleting the most current fetched cursor row
using the UPDATE/DELETE … WHERE CURRENT OF statement is not valid.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with SQL Queries
•
The default table type is SET, which does not allow duplicate rows.
•
The TRIM function trims only trailing pad characters by default.
Note: Case specificity does not apply to CLOBs.
A transaction is a logical unit of work. The statements nested within the transaction either
execute successfully as a group or do not execute. A Teradata SQL transaction can be a single
Teradata SQL statement, or a sequence of Teradata SQL statements.
Transaction Processing in ANSI Session Mode
In ANSI mode, transactions are always implicitly started and explicitly closed.
A transaction initiates when one of the following happens:
•
The first SQL request in a session executes
•
The first request following the close of a previous transaction executes
The COMMIT or ROLLBACK/ABORT statements close a transaction.
If a transaction includes a DDL statement (including DATABASE and SET SESSION, which
are considered DDL statements in this context), it must be the last statement in the
transaction other than the transaction closing statement.
If an error is found in a request, then that request is aborted. Normally, the entire transaction
is not aborted; however, some failures will abort the entire transaction. Locks placed by
erroneous statements are not released.
Sessions in ANSI mode do not support BEGIN TRANSACTION/END TRANSACTION
statements.
Transaction Processing in Teradata Session Mode
In Teradata mode, transactions can be either implicit or explicit.
A request that is not enclosed by the BEGIN TRANSACTION and END TRANSACTION
statements is treated as an implicit transaction.
An implicit transaction can be one of the following:
•
A single DML statement
•
A macro or trigger
•
A multistatement request
DDL statements are not valid in a multistatement request and are therefore not valid in an
implicit transaction composed of a multistatement request.
Explicit transactions contain one or more statements enclosed by BEGIN TRANSACTION
and END TRANSACTION statements. The first BEGIN TRANSACTION initiates a
transaction and the last END TRANSACTION terminates the transaction. Explicit
transactions can contain multistatement requests.
When multiple statements are included in an explicit transaction, you can specify only a DDL
statement if it is the last statement, and is immediately followed by END TRANSACTION.
Teradata Data Warehouse Appliance 2690 Implementation Guide
143
Chapter 8: Querying the Database
Working with SQL Queries
If an error occurs, the request fails, the entire transaction is aborted and all locks are released.
Sessions in Teradata mode do not support the COMMIT statement. The END
TRANSACTION statement terminates a transaction with commit, while the ABORT and
ROLLBACK statements terminate a transaction with a rollback.
Setting the Session Mode
A system parameter specifies the default transaction mode for a site. You can override the
default transaction processing mode for a session using one of the following:
•
SessionMode field of the DBS Control Record
•
BTEQ command .SET SESSION TRANSACTION
•
Preprocessor2 TRANSACT() option
•
Session Mode field of the Teradata ODBC Driver Options
•
JDBC TeraDataSource.setTransactMode() method
•
SQL Assistant when defining a .Net data source
Reference Information
Information on...
Is available in...
• transaction, request, and statement
processing
• transaction processing in ANSI and
Teradata session mode
SQL Request and Transaction Processing
SQL statements for processing transactions:
SQL Data Manipulation Language
• BEGIN TRANSACTION/END
TRANSACTION
• COMMIT
• ABORT
• ROLLBACK
144
setting the SessionMode field of the DBS
Control Record
Utilities: Volume 1 (A-K)
using the SESSION TRANSACTION BTEQ
command
Basic Teradata Query Reference
setting the Session Mode field in the Teradata
ODBC Driver Options dialog box
ODBC Driver for Teradata User Guide
setting the Session Mode field when defining
a .Net data source using SQL Assistant
Teradata SQL Assistant for Microsoft Windows User
Guide
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Using SQL Assistant to Submit a Query
Using SQL Assistant to Submit a Query
You can use Teradata SQL Assistant to compose an ad hoc SQL query, submit it to Teradata
Database, and view the results from your Windows client. In addition to querying the
database, you can use SQL Assistant to create database objects, such as databases, tables, views,
and users.
If you have many SQL statements in a file and you want to run it as a batch job, Teradata
recommends that you use BTEQ instead. With BTEQ, you can scan saved query output for
errors. You can also use BTEQ to submit end-user queries.
When deciding which program to use for submitting queries, consider the following
comparisons:
BTEQ Capabilities
SQL Assistant Capabilities
• Allows use of conditional logic.
• Creates reports, which you can format and
print.
• Requires you to store queries in outside files,
which must be retrieved for reuse.
• Can load only 64K per LOB.
• Does not allow use of conditional logic.
• Returns results to a spreadsheet that can be
manipulated online or saved to Excel, HTML,
PDF, or another format.
• Keeps a history of previously used queries,
which you can select for reuse.
• Can load any LOB data that the database can
store.
• Can display pictures as part of the result set.
For more information on BTEQ, see “Working with the Basic Teradata Query Utility” on
page 122 and “Appendix C Advanced Features” on page 291.
Prerequisites
You must install the following software before using Teradata SQL Assistant:
•
Microsoft .NET Framework. See “Installing Microsoft .NET Framework” on page 66.
•
.NET Data Provider for Teradata. See “Installation Guidelines” on page 64.
•
ODBC Driver for Teradata. See “Working with ODBC Data Sources” on page 71, which
also describes how to define a Teradata data source (connection to the database).
Executing a Query Using SQL Assistant
1
To start Teradata SQL Assistant, select:
Start > Programs > Teradata Client > Teradata SQL Assistant
2
On the toolbar, select ODBC from the drop-down list located next to the Connect button
.
Teradata Data Warehouse Appliance 2690 Implementation Guide
145
Chapter 8: Querying the Database
Using SQL Assistant to Submit a Query
(or select Tools > Connect).
3
Click the Connect button
4
Select the Teradata data source “Setting up Teradata as an ODBC Data Source” on page 71.
5
Enter your Username and Password. For example, log on as user DBADMIN.
6
Do one of the following:
7
•
Enter an SQL statement in the Query Window.
•
Drag and drop a file from Windows Explorer into the Query Window.
Click the Execute button
(or right-click in the Query Window and select Execute).
Executing Multiple SQL Statements in Parallel
You can run an entire query as a single request, allowing the database to execute all the
statements in parallel. To do this:
1
Enter multiple SQL statements in the Query Window.
2
Click the Execute Parallel button
(or select Tools > Execute Parallel).
Reference Information
Information on...
Is available in...
setting query options
Teradata SQL Assistant for Microsoft Windows User Guide
setting formatting options for a query
executing multiple SQL statements in a
single request
146
“Using Single and Multistatement Requests” on page 140.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with Commonly Used Queries
Working with Commonly Used Queries
The most commonly used and useful SQL queries include:
•
SELECT
•
INSERT
•
UPDATE
•
DELETE
For more details, including the complete syntax, see SQL Data Manipulation Language.
Using the SELECT Statement
The SELECT statement retrieves stored data from a table. All rows, specified rows, or specific
columns of all or specified rows can be retrieved. The FROM, WHERE, ORDER BY,
DISTINCT, WITH, GROUP BY, HAVING, and TOP clauses provide for a fine detail of
selection criteria.
To obtain data from specific rows of a table, use the WHERE clause of the SELECT statement.
That portion of the clause following the keyword WHERE causes a search for rows that satisfy
the condition specified.
Example 1: SELECT Request With a WHERE Clause
The following SELECT request returns the last name of the employee who is employee
number 1023, works in department 501, and was hired in 2006.
SELECT last_name
FROM Employee
WHERE employee_number = 1023
AND dept_number = 501
AND hire_date BETWEEN DATE '2006-01-01' AND DATE '2006-12-31';
Example 2: SELECT Request With a Subquery
The following SELECT request uses a subquery to return the names of the employees who
have the highest salary in each department.
SELECT name
FROM personnel p
WHERE salary = (SELECT MAX(salary)
FROM personnel sp
WHERE p.department=sp.department);
Using the INSERT Statement
Example 1: INSERT Request
You can use the INSERT statement to add a new row to a table. The following INSERT request
creates a local instance of global temporary table globdb.gt1 and populates it with a single row
having the following values: f1=1, f2=980101, f3=11.1
INSERT globdb.gt1 (1, 980101, 11.1);
Teradata Data Warehouse Appliance 2690 Implementation Guide
147
Chapter 8: Querying the Database
Working with Commonly Used Queries
Example 2: INSERT...SELECT Request
You can use the INSERT … SELECT form of the statement to perform a bulk insert of rows by
retrieving the new row data from another table. The following INSERT...SELECT request
copies all the rows from table t3 and inserts them into table t1:
INSERT t1 SELECT * from t3;
Using the UPDATE Statement
You can use the UPDATE statement to modify data in one or more rows of a table. In the
UPDATE statement, you must specify the column name of the data to be modified along with
the new value. You can also use a WHERE clause to qualify the rows to change.
After you create the following table and insert values into it:
CREATE SET TABLE t1 (
a INTEGER,
b INTEGER)
PRIMARY INDEX (a);
INSERT INTO t1 VALUES (1,1);
INSERT INTO t1 VALUES (1,2);
in the following UPDATE example, you update the table by decreasing the value of b by 1
whenever a =1.
UPDATE t1
SET b = b - 1
WHERE a = 1;
Using the DELETE Statement
The DELETE statement allows you to remove an entire row or rows from a table. A WHERE
clause qualifies the rows that are to be deleted.
The following example counts how many books by a publisher exist in the library. If the
answer is 0, the request deletes the row for that publisher.
DELETE FROM Publisher
WHERE 0 = (SELECT COUNT(*)
FROM book, publisher
WHERE book.PubNum=Publisher.pubnum);
Reference Information
148
Information on...
Is available in...
the INSERT, SELECT UPDATE, and
DELETE statements
SQL Data Manipulation Language
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with Macros
Working with Macros
Teradata Database supports macros, which consist of one or more SQL statements that are
stored as a database object.
When you execute the macro, Teradata Database runs the SQL statements within the macro as
a single request. Therefore, the system processes either all of the SQL statements successfully
or none of the statements. Users do not receive responses to individual statements contained
in the macro body until all the statements have been completed successfully.
Macros do not use any space. Only the macro definitions are stored in the Data Dictionary.
You can create a macro for your own use, or grant execution authorization to others.
Macros provide the following benefits:
•
Easy execution of simple, frequently-used SQL operations.
•
Useful for enforcing data integrity rules.
•
Useful for enforcing data security.
•
Multistatement requests can provide a performance benefit.
•
Can be used to define an appropriate level of locking.
To ensure data integrity and system security, Teradata recommends the following:
•
Set privileges so that general users cannot access or modify data tables directly.
•
Create macros which allow general users to access or modify only the table data they need.
Use macros to restrict users to performing specific queries and update functions.
•
Create macros in a Views Database. See “Working with Databases” on page 99.
Instead of using macros, you may want to use procedures to execute more complex queries.
Procedures can process control and condition handling statements, as well as SQL statements.
See “About Procedures and External Procedures” on page 291 and “Differences Between
Macros and Procedures” on page 291.
Creating Macros
The following procedure shows how to create macros using BTEQ:
1
Log on to Teradata Database as user DBADMIN using BTEQ. See “Working with the Basic
Teradata Query Utility” on page 122.
2
Create one or more macros using the CREATE MACRO statement. For example:
CREATE MACRO database_name.macro_name
(parameter_name data_type,
parameter_name data_type,
parameter_name data_type) AS
(SQL_statement;
SQL_statement;
SQL_statement;);
where:
Teradata Data Warehouse Appliance 2690 Implementation Guide
149
Chapter 8: Querying the Database
Working with Macros
Syntax Element
Explanation
database_name
The name of the database where the macro will be created if it is different
from the current database.
Recommendation: Specify the Views Database or a database located in the
Views Database. See “Working with Databases” on page 99.
If database_name is not specified, the system creates the macro in the
default database for the current session.
macro_name
The name of the macro. The name must be unique within the database
where it is created. Two identically named objects, for example, a macro
named Test and a table named Test, cannot coexist in the same database.
parameter_name
The name of a parameter used for passing a value to the macro during
execution. Parameters cannot be used for database object names. When
referenced in the macro body, you must prefix a parameter name with the
colon (:) character.
data_type
The data type of the parameter value.
SQL statement
A valid SQL statement to be executed when the macro is performed. The
following rules apply:
• A macro can include an EXECUTE statement that executes another
macro.
• For security reasons, the CREATE AUTHORIZATION or REPLACE
AUTHORIZATION statements are not allowed within a macro.
• A data definition statement is allowed in a macro if it is the only SQL
statement in that macro.
Unqualified references to database objects in a data definition statement
are not resolved when the macro is created. They are resolved using the
default database for the user submitting the EXECUTE statement when the
macro is performed.
Unqualified references to database objects in DML statements are resolved
using the default database for the user submitting the CREATE MACRO
statement when the macro is created.
Recommendation: Fully qualify all references to database objects in the
macro body for clarification.
Note: The example is the minimum recommended specification for creating a macro. You
can specify additional macro options in the initial CREATE MACRO statement, or add
them later using the REPLACE MACRO statement.
The following are common optional macro elements that you can specify in the CREATE/
REPLACE MACRO statement.
150
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with Macros
Syntax Element
Explanation
data_type_attributes
The data type attributes, such as NOT NULL, UPPERCASE, or TITLE.
Not all of the data attributes that can be specified for table columns can
be specified in macros. For example, the following attributes cannot be
used with macro parameters:
• CHECK constraints
• COMPRESS phrase
USING modifier
Defines one or more parameters used to retrieve data from an external
source such as a client data file.
LOCKING modifier
Specifies the type of lock placed on a database, table, view, or row hash
referenced by the subsequent SQL statement. Object referenced by a
request are locked until the macro transaction is complete.
Recommendation: Use the LOCKING FOR ACCESS modifier to
prevent deadlocks and increase performance, allowing concurrent
access by read-only users and users who are modifying the data.
ACCESS locking is a tool that can be used to reduce the isolation of a
user request, allowing that request to access valid, but uncommitted
data that is subject to change.
Users that do not require precise results can access the data while
modifications to the data are occurring. This can greatly improve
performance because the users do not have to wait for the write
operation to complete. For more information on the LOCKING clause,
see “Working with Database Locks” on page 153.
To automate the creation of macros by using BTEQ scripts, see “Using BTEQ Scripts to
Create Database Objects” on page 123.
3
Set privileges on the macro as follows:
•
Provide general users read-only access so they can use the macro to query data.
•
Provide privileged users with access so they can use the macro to modify data and
database objects.
See Chapter 10: “Setting Up Users,” for information about granting privileges on the
macro to users.
Example Macro
You can create macros to perform specific, narrow functions, such as adding a new employee
into the database. By using a macro to perform this function, you limit the user to performing
only the actions in the macro, which reduces the chance for errors. Also, the task is simpler to
perform: executing the macro is easier than coding the INSERT statement.
The following request creates the New_Employee macro which inserts a row for a new
employee in the Employee table, then performs a SELECT to verify that the information was
entered correctly. If the user does not provide a value for Dept_No, the macro automatically
inserts the value 300 as the default department number.
Teradata Data Warehouse Appliance 2690 Implementation Guide
151
Chapter 8: Querying the Database
Working with Macros
CREATE MACRO Views_Database.New_Employee
(Associate_Id
INTEGER,
Associate_Name
CHAR(25),
Salary
DECIMAL(8,2),
DOB
DATE,
Job_Title
VARCHAR(25),
Dept_No
SMALLINT DEFAULT 300,
Marital_Status
CHAR,
No_Of_Dependents BYTEINT) AS
(INSERT INTO Tables_Database.Employee (Associate_Id, Associate_Name,
Salary, DOB, Job_Title, Dept_No, Marital_Status, No_Of_Dependents)
VALUES (:Associate_Id, :Associate_Name, :Salary, :DOB, :Job_Title,
:Dept_No, :Marital_Status, :No_Of_Dependents);
-- The following SELECT verifies the INSERT
SELECT *
FROM Tables_Database.Employee
WHERE Associate_Id = :Associate_Id; );
The example uses the -- comment construct to include a comment in the macro. Text
appearing after -- and up to the end of the line is not performed.
After you create the macro, execute it as follows:
EXECUTE New_Employee (126, 'Taylor', 78000.00, '1978-12-29', 'Engineer',
400, 'S', 0);
You must have EXECUTE privilege on the macro.
Reference Information
For step...
Information on...
Is available in...
2
overview of macros
• Database Administration
• SQL Fundamentals
2, 4
syntax, options, required privileges for:
SQL Data Definition Language
• CREATE MACRO/REPLACE MACRO
• RENAME MACRO
• DROP MACRO
152
2
executing macros
SQL Data Manipulation Language
2
the default database
SQL Fundamentals
2
data types and data type attributes
• “About Teradata Data Types” on
page 283
• SQL Data Types and Literals
2
USING request modifier
SQL Data Manipulation Language
2
LOCKING request modifier
“Working with Database Locks” on
page 153.
2
optimizing query performance with macros
Database Design
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with Database Locks
Working with Database Locks
About Locks and Lock Levels
Teradata Database may use a different transaction isolation model than your current database.
You should review the transaction isolation needs of your queries and ensure that you have
chosen the proper isolation level and method when migrating to Teradata.
The Teradata Lock Manager imposes concurrency control by locking the database object being
accessed by each transaction and releasing those locks when the transaction either commits or
rolls back its work.
The Lock Manager can lock an object at the following levels:
Lock Level
Description
Database
Applies to all tables and views in the database.
All rows of all tables and their associated secondary index subtables are
locked.
Table
All rows in a base table and in any associated secondary index and fallback
subtables are locked.
View
All underlying tables accessed by the view, including associated secondary
indexes and fallback subtables are locked.
Row Hash
The primary copy of rows sharing the same row hash value are locked.
A row hash lock permits other users to access other data in the table. It is
applied to the set of rows that shares the same hash code. It does not
necessarily lock only one row.
A row hash lock is applied whenever a table is accessed using a unique
primary index (UPI). For an update that uses a unique secondary index
(USI), the appropriate row of the secondary index subtable is also locked.
It is not necessary to lock the fallback copy of the row, nor any associated
row, of a nonunique secondary index (NUSI) subtable.
The available lock severities, from most restrictive to least restrictive, are listed in the following
table. The CHECKSUM and ACCESS locking severities are at the same level of restrictiveness.
Teradata Database always makes an effort to lock database objects at the least restrictive level
and severity possible, to ensure database integrity while maintaining maximum concurrency.
Lock Severity
Description
EXCLUSIVE
Placed only on a database or table when the object is undergoing structural
changes or when a database is being restored, copied, rolled back, rolled forward,
or built by an Archive/Recovery utility command.
An EXCLUSIVE lock restricts access to the object by any other user.
Teradata Data Warehouse Appliance 2690 Implementation Guide
153
Chapter 8: Querying the Database
Working with Database Locks
Lock Severity
Description
WRITE
Placed in response to an INSERT, UPDATE, or DELETE request or when a set of
database objects is being recovered or restored by an Archive/Recovery utility
command.
A WRITE lock enables a single user to modify the data and restricts access to the
object by any other user, including those who want to read the object. However, if
you are not concerned with data consistency, you can override the WRITE lock
and read the data using an ACCESS lock.
READ
Placed in response to a read operation such as a SELECT request. Archive
requests can also place READ locks on database resources.
Multiple users can concurrently hold a READ lock on a base table. As long as a
READ lock is in place, no modification of the object is allowed.
CHECKSUM
Placed in response to a user-specified LOCKING FOR CHECKSUM modifier
when using cursors in embedded SQL and procedures.
CHECKSUM locking is identical to ACCESS locking except that it adds
checksums to the rows of a spool file to allow a test of whether a row in the cursor
has been modified by another user or session at the time an update is being made
through the cursor.
ACCESS
Placed in response to a user-specified LOCKING FOR ACCESS modifier, or by
setting the session default isolation level to READ UNCOMMITTED using the
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL
statement.
An ACCESS lock does not restrict access by another user except when an
EXCLUSIVE lock is required.
ACCESS locking can be used to reduce the isolation of a user request. It permits a
user to have READ access to an object that might already be locked for READ or
WRITE. Because the data selected using an ACCESS lock might be modified
concurrently while the object is being read, any query that requests an ACCESS
lock will return valid, but uncommitted data that is subject to change. Therefore,
the ACCESS lock is sometimes referred to as a dirty READ lock.
When using ACCESS locks, it is the responsibility of the database designer and
the data requester to ensure the proper level of data consistency for each user.
This gives the designer a wide degree of flexibility in determining how data can
be accessed.
Recommendation: To prevent deadlocks and improve performance, use
ACCESS locks whenever you are interested in a broad, statistical snapshot of the
data, but you do not require precise results.
154
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Working with Database Locks
Changing the Default Lock Level
The Lock Manager imposes locks automatically. You can use the SQL LOCKING request
modifier to override the default lock severities. You can use LOCKING with DML statements
and with most DDL, DCL, SHOW, and HELP statements. In particular, you can use
LOCKING with the CREATE INDEX and COLLECT STATISTICS statements to prevent
deadlocks. You can also use the LOCKING request modifier when defining views.
For example:
LOCKING lock_level object_name FOR lock_severity [NOWAIT] SQL_request;
where:
Syntax Element
Explanation
lock_level
Keyword specifying the level of the lock to be placed. The available lock levels
are: DATABASE, TABLE, VIEW, and ROW.
The keyword ROW indicates that a row-hash level lock should be used.
Recommendation: Always specify the appropriate keyword. This clarifies which
database object should be locked in case you have two database objects with the
same name (for example, you have both a table and a database named Accounts).
object_name
Specifies the name of the database, user, table, or view to be locked.
lock_severity
Specifies the severity level of the lock to be used. The available lock severities are:
ACCESS, READ, WRITE, EXCLUSIVE, and CHECKSUM.
NOWAIT
If the indicated lock cannot be obtained, the request should be aborted.
Recommendation: Specify this option for situations in which it is not desirable
to have a request wait for resources, and possibly tie up resources another request
could use.
SQL_request
Specifies a valid SQL request.
The specified lock will be used instead of the default lock while processing this
SQL request. The lock will remain for the duration of the transaction containing
this SQL request.
The following rules apply:
• You can specify an EXCLUSIVE lock for a DELETE, INSERT, MERGE,
SELECT, SELECT AND CONSUME, or UPDATE statement.
• You can specify a WRITE, READ, or ACCESS lock for a SELECT statement.
• You can specify a CHECKSUM lock only when using cursors in embedded
SQL or procedures.
• You cannot specify LOCKING with the CALL statement.
• You can specify LOCKING with most DDL, DCL, SHOW and HELP
statements.
When a view is defined with a LOCKING modifier, the specified lock is placed on all
underlying base tables each time the view is referenced in an SQL request. For example, if a
view refers to tables t1 and t2, then a lock on that view would apply to both tables.
Teradata Data Warehouse Appliance 2690 Implementation Guide
155
Chapter 8: Querying the Database
Working with Database Locks
Example 1: Using the LOCKING Clause
The following LOCKING clause can be used to select data from the Employee table while it is
being modified. This allows users quick access to the data without having to wait for any write
operation to complete, and is perfect for users who need a statistical sample of the data, but do
not require precise results.
LOCKING TABLE Tables_Database.Employee FOR ACCESS
SELECT Associate_Name, Salary
FROM Tables_Database.Employee
WHERE salary < 25000;
Example 2: LOCKING Multiple Objects
Multiple LOCKING modifiers can precede a request if it is necessary to lock more than one
object at the same time, for example:
LOCKING TABLE Employee FOR ACCESS
LOCKING TABLE Department FOR ACCESS
SELECT Associate_Name, Location
FROM Employee, Department
WHERE (Associate_Id = Manager_Id);
Example 3: Converting FOR UPDATE to a Locking Modifier
In Oracle, the FOR UPDATE clause of the SELECT statement allows you to lock the selected
rows so that other users cannot modify the rows until your transaction ends.
You can use the LOCKING modifier to get the same result in Teradata:
LOCKING ROW FOR WRITE
SELECT ...
Monitoring and Managing Locks
You can use the following tools to monitor and manage locks:
•
EXPLAIN request modifier
Use EXPLAIN with your SQL request to determine what locks are set when the request is
executed.
•
Lock Viewer portlet in Teradata Viewpoint allows you to view lock data such as
transaction, session, and lock object identifiers, and global deadlocks.
You can locate locks:.
•
•
In a specific database
•
Within a time frame
•
Caused by a specified user
•
That are blocking a specified user
Lock Display (lokdisp) and Locking Logger (dumplocklog) utilities
These utilities allow you to review all the active locks and analyze lock contention issues
among concurrent SQL statements. You can:
156
•
Run Lock Display from the Teradata Viewpoint Remote Console portlet
•
Get a report based on dumplocklog data from the Lock Viewer portlet
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 8: Querying the Database
Checkpoint
Reference Information
Information on...
Is available in...
managing locks
Database Administration
locking and transaction processing
SQL Request and Transaction Processing
syntax and options for the LOCKING
request modifier
SQL Data Manipulation Language
guidelines for changing default lock
assignments
SQL Data Manipulation Language.
syntax and options for the SET SESSION
CHARACTERISTICS AS TRANSACTION
ISOLATION LEVEL statement
SQL Data Definition Language
session isolation level
SQL Data Definition Language
specifying locking in views
“Working with Views” on page 117.
the EXPLAIN request modifier
“Using EXPLAIN to Analyze Query Plans” on
page 162.
using the Lock Display (lokdisp) utility to
display all active database locks
Utilities: Volume 2 (L-Z)
using the Locking Logger utility to set up
lock logging
• “Locking Logger” in Utilities: Volume 2 (L-Z)
• “Setting Up Lock Logging Parameters” on
page 226
using Teradata Viewpoint to investigate
locks, blocked users and blocked sessions
“Investigating Query Blocks and Delays” on page 229
Checkpoint
Before leaving Chapter 8: “Querying the Database,” make sure that:
√
Result
Reference
You know several ways of invoking SQL
statements in Teradata.
“Working with SQL Queries” on page 139
You understand the implications of ANSI
and Teradata session modes.
“About Session Modes and Transaction
Processing” on page 142
You understand the differences between
Teradata and ANSI SQL.
“About Differences Between Teradata SQL
and ANSI SQL” on page 141
You can execute a query in SQL Assistant.
“Using SQL Assistant to Submit a Query”
on page 145
Teradata Data Warehouse Appliance 2690 Implementation Guide
157
Chapter 8: Querying the Database
Checkpoint
√
Result
Reference
You can create macros in BTEQ and SQL
Assistant.
“Working with Macros” on page 149
• You understand the default lock levels in
Teradata Database, and how to change
them.
• You know which utilities monitor locks.
• You ensured that you chose the proper
transaction isolation level when
migrating to Teradata.
“Working with Database Locks” on
page 153.
If you do not have these results, return to the section in the Reference column and review that
procedure.
158
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 9
Optimizing Query Performance
After creating and populating database tables, you can take various actions in the database
that help the Teradata Optimizer to handle queries more efficiently.
Task Overview
The tasks and procedures presented in this section are strongly recommended and should be
performed completely and in the order shown to optimize Teradata Database queries:
1
Collect statistics on table columns. Identify stale statistics and recollect when necessary.
See “Using COLLECT STATISTICS to Optimize Query Performance” on page 159.
2
Analyze query plans using EXPLAIN and optimize query construction based on the
analysis. See “Using EXPLAIN to Analyze Query Plans” on page 162.
3
Use secondary indexes and join indexes to optimize query processing. See “Using Indexes
to Improve Query Performance” on page 163.
4
After any query optimization change, rerun the query to measure performance differences
and determine whether the changes achieved the desired result.
5
Repeat step 2 through step 4 until you get satisfactory performance with correct query
results.
Using COLLECT STATISTICS to Optimize Query
Performance
About Statistics Collection
The COLLECT STATISTICS statement collects demographic information on table columns.
The Optimizer uses statistics to estimate the comparative processing costs for various ways of
executing a query, and determines the best query plan. Statistics include:
•
Unique column values
•
Maximum rows/value
•
Typical rows/value
•
Number of null rows
The Optimizer does not accept pragmas or hints, and bases query plans only on statistics.
The Optimizer automatically does a random AMP sample to gather rudimentary statistics
when a query accesses data with no statistics, but these statistics may not be optimal.
Teradata Data Warehouse Appliance 2690 Implementation Guide
159
Chapter 9: Optimizing Query Performance
Using COLLECT STATISTICS to Optimize Query Performance
Required Privileges
You must have STATISTICS privileges on a table (except a volatile table) or index to run a
COLLECT STATISTICS request.
Resource Considerations
Collecting statistics normally involves a full-table scan, so you may need to collect statistics for
large tables during off-hours.
For very large tables, you can also collect statistics on a sampled subset of table rows instead of
all the rows for a table, using the SAMPLE clause.
When to Collect Statistics
Collect statistics at the following phases of table development:
•
Newly created, unpopulated tables.
Collect statistics on unpopulated tables to set up the interval histogram used in internal
processing. This initial collection makes subsequent statistics collections faster. Make sure
to recollect statistics after data is added.
•
Prototype phase, newly populated tables.
•
Production phase, after a significant percentage of change to the table (~10%).
Recommendation: Collect production phase statistics after you have created users and
applied real world query loads to the database (up to about 3 months of querying).
Collecting Statistics
Use the COLLECT STATISTICS statement to define the table columns on which you want to
collect statistics, for example:
COLLECT STATISTICS ON database_name.table_name COLUMN (column_1,
column_2 ...);
At minimum, you should collect statistics on the primary index (PI) of each table. For small
tables (<100 rows per AMP) PI statistics may be sufficient.
For best results on larger tables, collect statistics on:
160
•
All indexed columns
•
All frequently joined columns
•
Columns frequently referenced in WHERE clauses, particularly if the column contains
very skewed, nonunique data
•
The system-derived column PARTITION (for a table or join index with partitioning)
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 9: Optimizing Query Performance
Using COLLECT STATISTICS to Optimize Query Performance
Reference Information
Information on...
Is available in...
collecting statistics
Database Administration
syntax and options for the COLLECT
STATISTICS statement
• SQL Data Definition Language Syntax and Examples
• SQL Data Definition Language Detailed Topics
Teradata Statistics Wizard utility
Teradata Statistics Wizard User Guide
Stale Statistics
Although the system has some ability to extrapolate reasonable estimates for rows added since
statistics were last collected, statistics that are far out of date (stale) may be worse for
Optimizer query planning than having no statistics at all.
Recommendations: Recollect statistics if there is more than a 10% change in row count
(added or deleted) within a table, or for partitioned tables, in a partition. For high volumes of
nonunique values, such as dates and timestamps, recollect after a 7% change.
Note: If the current statistics are stale, but you do not want to recollect them because of
resource contention, you can temporarily drop the statistics using the DROP STATISTICS
command, and use the default statistics automatically collected by the system. However, you
should recollect new statistics at the earliest opportunity.
Recollecting Statistics when Existing Statistics Are Stale
1
Run the following SQL request to determine the current row count for a table:
SELECT COUNT(*)
FROM database_name.table_name;
Count(*)
----------9203
2
Use the HELP STATISTICS statement to generate a report for the table row count at the
previous statistics collection point, for example:
HELP STATISTICS database_name.table_name;
Date Time Unique Values Column Names
-------- -------- ------ ---------------------------09/11/03 12:39:55 17 M22_D_DEB_V_ID
09/11/03 12:40:09 2,095 P66_C_CODE_ID
09/11/03 13:57:17 2,275 M22_D_DEB_V_ID,P66_C_CODE_ID
3
Because the row count has increased substantially, you should recollect statistics.
COLLECT STATISTICS ON database_name.table_name
Note: You do not have to specify the table columns again when you recollect statistics. The
system automatically collects statistics on the columns specified for the initial collection.
Teradata Data Warehouse Appliance 2690 Implementation Guide
161
Chapter 9: Optimizing Query Performance
Using EXPLAIN to Analyze Query Plans
Using EXPLAIN to Analyze Query Plans
About the EXPLAIN Request Modifier
The EXPLAIN request modifier reports an English language summary of the query plan
generated by the Optimizer to process any valid SQL request. The summary describes the
AMP steps the system would perform to resolve the request, but the request is not processed.
Note: To EXPLAIN a request, you must have the privileges required to execute the request.
EXPLAIN is useful for evaluating and optimizing SQL queries. It provides a summary of the
access and join plans generated by the Optimizer for the specified SQL request, including
information such as:
•
the indexes to be used
•
any intermediate spool files that will be generated
•
the join types to be performed
•
whether the requests in a transaction will be dispatched in parallel
•
the relative time it will take to complete the request
Using EXPLAIN allows you to compare the relative performance of the different versions of a
query and choose the most efficient SQL.
Recommendation: Always use EXPLAIN to analyze any new queries under development.
Subtle differences in the way a query is structured can produce significant differences in its
resource impact and performance, even though the queries may produce identical end results.
Administrators can use EXPLAIN interactively to examine queries that are consuming too
many resources. See “Identifying Bad Queries” on page 227.
Generating an EXPLAIN with SQL Assistant
1
In the SQL Assistant Query window, enter the SQL query to be EXPLAINed.
2
Press F6.
For more information, see Teradata SQL Assistant for Microsoft Windows User Guide.
Generating an EXPLAIN with BTEQ
To generate an EXPLAIN for an SQL request, add the word “EXPLAIN” at the beginning of
the request.
For example, the following SQL performs an EXPLAIN on a SELECT statement:
EXPLAIN SELECT * FROM Employee;
162
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Reference Information
Information on...
Is available in...
syntax and options for the
EXPLAIN request modifier
SQL Data Manipulation Language
interpreting the output of the
EXPLAIN request modifier for
various request types
SQL Request and Transaction Processing
Teradata Visual Explain utility
Teradata Visual Explain User Guide
Using Indexes to Improve Query Performance
About Indexing Options
The process of creating a table includes specifying a primary index, which assists the system to
evenly distribute table data and efficiently process requests that access the table.
After collecting statistics to aid query planning and using EXPLAINs to help enhance query
construction, allow the system to run for a few months while evaluating performance. If you
need to enhance performance, consider adding secondary indexes or join indexes.
Note: Teradata Database also supports hash indexes, which offer functionality similar to
single-table join indexes, but using a different syntax. See Database Design.
Secondary indexes and join indexes can provide a more efficient path to the data by avoiding
full-table scans when locating the relatively small number of rows that a query typically
retrieves or updates.
You can create up to 32 indexes for one table, using any combination of secondary, join, and
hash indexes. However, because Teradata parallel architecture allows the system to make
highly efficient full-table scans, you may only need to assign a few indexes to a table to get the
performance you need.
An index that supplies all the columns requested by a query is said to cover that query, and is
often referred to as a covering index. Retrieval times are usually faster when using a covering
index because the columns requested in the query can be retrieved from the index subtable
rather than accessing the underlying base tables.
When the index contains only some of the columns referenced in a query, the situation is
referred to as a partial cover of the query. Even a partial index cover can accelerate the
processing of a query by reducing (but not entirely eliminating) the need to access the base
tables.
Teradata Data Warehouse Appliance 2690 Implementation Guide
163
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Costs and Benefits of Secondary Indexes and Join Indexes
Secondary indexes and join indexes can provide many benefits:
•
Lower CPU usage
•
Greater concurrency
•
Faster response times for queries
There are also some disadvantages to using indexes:
•
Indexes must be updated every time a row is updated, deleted, or added to a table. The
more indexes you have defined for a table, the bigger the potential performance impact.
Sparse join indexes are updated only if the base row falls within the conditions of the
sparse join index.
•
All secondary indexes are stored in subtables. When you define FALLBACK for a table, the
secondary index subtables are always duplicated, which consumes additional disk space.
•
All join and hash indexes are stored in separate tables, causing a burden on disk space.
Defining FALLBACK for join or hash indexes consumes additional disk space.
When planning your indexes, you should always weigh the costs of an index against the
benefits to make sure that the costs do not neutralize or even reduce the overall performance
advantage of the index. For additional information, see Database Design.
About Secondary Indexes
Secondary indexes (SI) enhance single-row or set (multirow) selection by specifying access
paths other than the primary index path. During query processing, the Optimizer estimates
comparative costs to determine whether the use of a SI offers any savings. If no advantage can
be obtained with the SI, a different access method is used, such as a full-table scan.
Secondary indexes are useful for:
•
Queries having a search condition that cannot be satisfied with a primary index retrieval.
For example, it is common for WHERE clause search criteria to be based on non-primary
index columns, and such occasions often benefit greatly if there is an SI on the column
defined for the search criterion.
•
Query plans where the SI completely or partially covers the query.
•
Facilitating aggregate operations.
•
Optimizing repetitive and standardized queries.
•
Improving system performance in decision support environments.
Recommendation: Use unique secondary indexes for decision support applications
designed to return multiple rows, because the SIs may provide better performance than
full-table scans.
You can create a secondary index:
164
•
When you create the table. See “Working with Tables” on page 106.
•
In a CREATE INDEX statement. See “Creating Secondary Indexes” on page 166.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Unlike primary indexes, secondary indexes can be dropped and created without altering the
table they index. You can create or drop a secondary index when data usage changes, or if you
find that the index is not useful for optimizing data retrieval performance.
Unique and Nonunique Secondary Indexes
You can define the secondary index as unique (USI) or nonunique (NUSI), depending on
whether duplicate values are allowed in the indexed column set.
Unique secondary indexes have the following properties:
•
Can be used to enforce row uniqueness for multiset tables defined with a nonunique
primary index (NUPI).
•
Guarantee that each composite index value is unique.
•
Data access based on a USI is very efficient (at most a two-AMP operation).
•
Are always preferable to NUSIs for access using a single row, but are not as efficient as
NUSIs for range query access.
•
Is useful in partitioned primary index tables if defined on the set of primary index
columns when the primary index cannot be unique because it does not contain all the
partitioning columns.
•
Teradata does not use a USI unless all of the indexed columns are in the predicate.
Nonunique secondary indexes have the following properties:
•
Are typically assigned to nonunique column sets that frequently appear in WHERE clause
selection conditions, join conditions, ORDER BY and GROUP BY clauses, foreign keys,
and other conditions such as UNION, DISTINCT, and any attribute that is frequently
sorted.
•
Useful for locating rows having a specific (typically concatenated) value in the index.
•
Provide faster set selection, but USIs are more useful for retrieving single rows, particularly
when a base table has a nonunique primary index.
•
Can be hash-ordered or value-ordered.
Value-ordered NUSIs are particularly useful for enhancing the performance of range
queries against nonpartitioned primary index tables, especially when the NUSI covers the
query or is highly selective.
•
A multicolumn NUSI created with an ORDER BY clause counts as two consecutive
indexes against the maximum allowable 32 indexes.
Choosing a Secondary Index
When choosing columns for a secondary index for a table, the most important factor to
consider is the selectivity of the index. An index that retrieves fewer rows is said to be more
highly selective. The more highly selective an index is, the more useful it is for enhancing
performance. While USI retrievals are always very efficient, the efficiency of NUSI retrievals
varies greatly depending on selectivity.
You can use the Teradata Index Wizard utility to aid in choosing secondary indexes for a table.
The utility recommends a set of indexes based on specific query workloads you supply. The
Teradata Data Warehouse Appliance 2690 Implementation Guide
165
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Teradata Index Wizard can also validate its recommendations to ensure they actually provide
the benefits expected.
Guidelines
Use the following guidelines for selecting columns to be used as secondary indexes:
•
Avoid columns that are frequently updated.
•
Avoid columns with uneven distribution because the Optimizer might mistake their
usefulness.
•
Avoid creating excessive secondary indexes on a table.
•
Select column sets frequently involved in the following clauses, predicates, and other
logical operations:
•
Selection criteria
•
Join criteria
•
ORDER BY clauses
•
GROUP BY clauses
•
Foreign keys (because of join and subquery processing)
•
UNION, DISTINCT, and other sort operations
When these operations act on well-indexed column sets, the number of scans and sorts
that must be performed can be greatly reduced.
•
Consider creating covering indexes wherever possible. The Optimizer frequently selects
covering indexes to substitute for a base table access whenever the overall cost of the query
plan is reduced. Such index-only access promotes faster retrievals.
•
Select columns frequently operated on by built-in functions such as aggregates.
•
Avoid columns that do not enhance selectivity.
•
In some circumstances, multiple single-column indexes may be a better choice than using
composite secondary indexes.
•
Select columns that do not have any of the following data types: BLOB, CLOB, Period,
UDT, ST_Geometry, MBR.
Creating Secondary Indexes
The following procedure shows how to create an index using BTEQ:
1
Log on to Teradata Database as user DBADMIN using BTEQ. See “Working with the Basic
Teradata Query Utility” on page 122.
2
Create one or more secondary indexes using the CREATE INDEX statement. For example:
CREATE [UNIQUE] INDEX index_name
(index_column_name,
index_column_name,
index_column_name)
ON database_name.table_name;
where:
166
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Syntax Element
Explanation
UNIQUE
Specifies that no two rows in the table can have the same value or
combination of values in the indexed columns.
index_name
Specifies an optional name for the secondary index.
Recommendation: Specify a name for the secondary index using a
standard naming convention.
index_column_
name
Specifies one or more columns whose values are to be indexed. If you
specify more than one column, the index is created on the combined values
of each column. You can specify up to 64 columns. See “Choosing a
Secondary Index” on page 165.
database_name
The name of the database where table_name is located if it is different from
the current database. The table should be located within the
Tables_Database, as shown in “Creating the Tables Database” on page 100.
If database_name is not specified, the system looks for the table in the
default database for the current session.
table_name
The index will be created for this table.
Note: The example is the minimum recommended specification for creating a secondary
index. Additional options are available. For a complete description of all available options,
see “CREATE INDEX” in SQL Data Definition Language Syntax and Examples.
You can modify the index by dropping it (DROP INDEX) and recreating it.
Example 1: Creating a Named Unique Secondary Index
The following statement creates a unique secondary index named Ident on the
Associate_Name and SocSecNo columns of the Employee table:
CREATE UNIQUE INDEX Ident (Associate_Name, SocSecNo) ON
Tables_Database.Employee;
This definition allows the named index to be dropped by using its name:
DROP INDEX Ident ON Tables_Database.Employee;
Example 2: Creating an Unnamed Nonunique Secondary Index
The following statement creates a nonunique secondary index on the Dept_No column of the
Employee table:
CREATE INDEX (Dept_No) ON Tables_Database.Employee;
The UNIQUE option is not used because multiple rows contain the same department
number. The index should be useful, however, because department numbers are often used
for conditional retrievals and for ordering employee listings.
The following statement drops this index:
DROP INDEX (Dept_No) ON Tables_Database.Employee;
Teradata Data Warehouse Appliance 2690 Implementation Guide
167
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Join Indexes
A join index allows the system to get requested data from an index rather than accessing and
joining their underlying base tables. When a join index can be used to fully satisfy a query, you
avoid the need to access multiple base tables, perform joins or aggregates, or redistribute the
rows of very large tables, every time the query is run. You can define a join index on one or
several tables.
Join indexes can also be useful for queries where the index structure contains only some of the
columns referenced in the statement. This situation, referred to as a partial cover of the query,
reduces (but not entirely eliminates) the need to access the base tables.
You can define the primary index for a join index on a column set that differs from the
column set used to define the primary index on the base table. This facilitates joins by
redistributing rows of frequently joined tables to the same AMP. You can also define
nonunique secondary indexes on a join index.
You can create the following types of join indexes:
•
•
•
Single-table join index
•
Very useful for resolving joins on large tables without having to redistribute the joined
rows across the AMPs.
•
Can be used to establish an alternate primary index access opportunity.
•
Can be used to aggregate one or more columns of a single table as a summary table.
•
Can be used to establish a subset of columns that are frequently accessed to improve
access to those columns.
Multitable join index
•
Stores and maintains the joined rows of two or more tables and, optionally, aggregates
selected columns.
•
Used for join queries that are performed frequently enough to justify defining a prejoin
on the joined columns. Prejoins are also known as materialized views.
•
Useful when the index covers the query, making it possible to retrieve the requested
data from the index rather than accessing the underlying base tables.
Aggregate join index
This index is extremely efficient in resolving queries that frequently specify the same
aggregate operations on the same column or columns. When aggregate join indexes are
available, the system does not have to repeat aggregate calculations for every query.
•
Sparse join index
This index stores a subset of the rows from the underlying base table set based on a
WHERE clause condition. This makes it possible for a smaller join index to be used in
answering queries.
Recommendation: Use join indexes for decision support applications because they often
provide superior performance to large table joins and aggregate computations.
To create a join index, use the CREATE JOIN INDEX statement. To create a sparse index, use
the WHERE clause in the CREATE JOIN INDEX statement.
168
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Example Join Index
Suppose that a common task is to look up recent customer orders by customer number and
date. You might create a join index like the following, linking the customer table, the order
table, and the order detail table:
CREATE JOIN INDEX cust_ord2 AS
SELECT cust.customerid, cust.loc, ord.ordid, item, qty, odate
FROM cust, ord, orditm
WHERE cust.customerid = ord.customerid
AND ord.ordid = orditm.ordid
AND odate >= DATE '2009-08-01'
PRIMARY INDEX (customerid);
Validating and Maintaining Indexes
After you design your indexes and queries, and after you have run your workloads for a while
(approximately 30 days, depending on workload), it is important that you test your indexes to
ensure that they are being used as planned, and providing the benefits you expect.
Perform the following steps regularly to verify and maintain your indexes:
1
Collect/re-collect statistics so that the Optimizer has the current column demographics to
select the appropriate indexes when processing a query or update. See “Using COLLECT
STATISTICS to Optimize Query Performance” on page 159.
You can use the Teradata Statistics Wizard client utility at regular intervals to recommend
the columns and indexes on which you should collect statistics for particular query
workloads. The Statistics Wizard also recommends when statistics should be recollected
on those columns.
2
Use the EXPLAIN request modifier or the Visual Explain tool to test various candidate
queries or updates and to note which indexes (if any) are used by the Optimizer. Also,
examine the relative length of time required to complete the operations.
3
Use the Teradata Index Wizard client utility to recommend and validate sets of secondary
or single-table nonsparse join indexes for a particular query workload. The Teradata Index
Wizard utility provides a “What-If Analysis” feature that allows you to see how an index
might perform for a given workload and compare the performance of different indexes for
the same workload.
4
Analyze the performance of an index to verify that the assumptions for choosing that
index are correct. In particular:
5
•
If you define a partitioned primary index (PPI) for a table, make sure the PPI actually
improves query performance over a nonpartitioned primary index by carefully
examining EXPLAIN reports and collecting the appropriate statistics.
•
If you design a primary index with even row distribution as your principal criterion,
analyze the actual distribution of table rows to ensure that they are evenly distributed.
Drop indexes that are rarely selected by the Optimizer. Unused indexes consume disk
resources and degrade update processing performance unnecessarily.
Teradata Data Warehouse Appliance 2690 Implementation Guide
169
Chapter 9: Optimizing Query Performance
Checkpoint
6
Drop indexes where the selectivity of the index is always low (the index always retrieves a
large number of rows). Evaluate the performance of the index in several different
situations to confirm its ineffectiveness before dropping it.
Check the query plans of the queries you most often use to see if the Optimizer is using your
indexes. If the Optimizer consistently chooses a full-table scan instead of using your indexes,
you need to redesign your indexes or refresh stale collected statistics.
Reference Information
Information on...
Is available in...
overview of indexes
• Database Administration
• SQL Fundamentals
designing and using indexes
• Database Design
• SQL Data Definition Language Detailed Topics
syntax and options for secondary indexes:
SQL Data Definition Language Syntax and Examples
• CREATE INDEX
• DROP INDEX
syntax and options for join indexes:
• CREATE JOIN INDEX
• DROP JOIN INDEX
Teradata Index Wizard utility
Teradata Index Wizard User Guide
Checkpoint
Before leaving Chapter 9: “Optimizing Query Performance,” make sure that:
√
Result
Reference
You collected statistics on tables.
“Using COLLECT STATISTICS to
Optimize Query Performance” on
page 159.
You know how to use the EXPLAIN request
modifier to analyze query plans.
“Using EXPLAIN to Analyze Query
Plans” on page 162.
You know how to implement secondary and join
indexes and have considered their costs and
benefits.
“Using Indexes to Improve Query
Performance” on page 163.
If you do not have these results, return to the section in the Reference column and review that
procedure.
170
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 10
Setting Up Users
This section presents the administrative tasks required to create users, provide them the
privileges necessary for their activity in the database, and log database activity.
Required Tasks
For best results, perform all the tasks in this section completely and in the order presented.
1
Group potential database users by functional group and determine database access needs.
See “User Evaluation” on page 171.
2
Set up user accounts to track resource usage and assign workload priorities. See “Working
with User Accounts” on page 173.
3
Set up profiles to define resources, account assignments, and password control parameters
for groups of users. “Working with Profiles” on page 175.
4
Create database users and assign profiles, space and accounts. See “Working with Database
Users” on page 179.
5
Create roles to define privileges for users groups and grant role membership to users.
“Using Roles to Manage User Privileges” on page 182.
6
Grant additional privileges that are not suitable for role assignment directly to users. See
“Granting Privileges Directly to Users” on page 190.
User Evaluation
About User Requirements
The following list identifies five typical user types and job functions.
Functional Category
Description
General users
Database end-users who only need to read the data or to run preexisting queries or macros to generate reports.
Update users
Privileged users who perform some general user functions and who
also may need to insert, update or delete data, and create new database
objects.
Teradata Data Warehouse Appliance 2690 Implementation Guide
171
Chapter 10: Setting Up Users
User Evaluation
Functional Category
Description
Batch users
High-level users who typically perform batch-level functions, for
example:
• Load, update, and export operations, including creation and deletion of
staging tables.
• Data backup, archive, and restore operations.
Database
programmers
Users who design and create queries, macros, and stored procedures, as well
as database objects, for use by the user community. Programmers may
require administrator privileges within a development database, while
needing only limited privileges in the main production database.
Assistant
administrators
Administrative users that assist the principal administrator, user
DBADMIN, created in Chapter 4, “Creating User DBADMIN” on
page 89. Assistant administrative users may have most or all of the
same privileges granted to user DBADMIN, but have a much smaller
permanent space allocation because they have a limited ownership of
objects
Note: You can create additional user types where necessary to identify functional differences,
however, the examples provided in this publication are based on these user types.
Determining Database User Needs
Assess database user needs and develop a user management strategy before you begin
executing user management setup tasks.
1
Create a list of all users that require access to Teradata Database and identify each one
according to user type. Minimize the number of user types to simplify user management.
2
Define user resource requirements for use in creating profiles:
•
•
172
Examine user space requirements.
•
Users that create or own databases, tables and other space-consuming objects
require permanent storage space (perm space).
•
Users that execute SQL queries, macros, or stored procedures require spool space to
contain the required temporary database structures. The spool specification in a
profile limits the amount of available space a profile member can use.
Define user accounting requirements for use in specifying one or more account strings.
Each profile can include one or more accounts. Each account can specify:
•
A priority level (low, medium, high, and rush)
•
A four-character account identifier based on department, group, or function.
•
A date and time stamp
•
Define the user default database, that is, the database where the user most often works.
•
Define password control parameters. Refer to the chapters on password controls and
managing passwords in Security Administration. Consider your site security policy and
decide whether or not all users can share global password parameters, or if you need to
set them by user group, in profiles.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Working with User Accounts
3
Review the database objects (such as views, tables, macros, functions, and procedures) that
users or user groups must access to do their job. Always define database privileges at the
highest level that is appropriate for a particular user. For example, if a user requires the
same privileges on all views in a database, assign privileges at the database level.
4
Identify groups of users with common database privilege requirements and create roles to
define the privileges for each group. Consolidate minor differences in access requirement
where possible to minimize the number of roles.
5
You may need to assign specialized privileges directly to individual users.
Working with User Accounts
About Accounts
Each user logon to the database should specify a user account string.
Accounts are used by the database to:
•
Assign priority to individual sessions to manage the workload
•
Monitor resource usage
•
Charge for space or resources used
Teradata recommends that you specify at least one user account for each user. Users with
similar responsibilities and resource requirements should be assigned to the same account(s)
to reduce the overall number of accounts you must maintain.
You can specify accounts in:
•
A CREATE PROFILE or MODIFY PROFILE statement for the profile specified in the user
definition (preferred).
•
A CREATE USER or MODIFY USER statement.
Note: If a user is a member of a profile that specifies one or more accounts, the profile
account assignments supersede and invalidate any accounts specified in the user
definition.
Reference Information
Information on...
Is available in...
specifying the account string at
logon
• Security Administration
• The logon section in the User Guide for each Teradata tool or
utility.
accounts
Database Administration
Teradata Data Warehouse Appliance 2690 Implementation Guide
173
Chapter 10: Setting Up Users
Working with User Accounts
Creating Account Strings
Teradata recommends that you devise an account system and then identify the accounts
required for various groups in the user community before attempting to specify account
information in user profiles. An account string is limited to 30 characters in length.
See also “Using Performance Groups to Manage Job Priorities” on page 230.
User account strings should follow this format:
‘$G0+account_ID&S&D&H’
Note: If a CREATE or MODIFY statement specifies more than one account string, the
individual strings must be separated by commas and the entire list of strings enclosed by
parentheses.
where:
Element
Description
Required Account String Variables
$G0+
Optional. The performance group identifier. Priority scheduler
uses the identifier to determine the priority of the session.
Recommendation: Specify one of the following instead of $G0+:
• $R0+ = Rush
• $H0+ = High
• $M0+ = Medium (default)
• $L0+ = Low
Note: Consider the following when specifying the performance
group.
• The 0 specification designates resource partition 0, the default
and only partition allowed on Teradata 2690.
• The + character is a place holder that forces the account_ID
to start at the fifth character, which is important for
compatibility with certain administrative tools.
account_ID
The account name. Uniquely identifies the account.
Recommendation: You can use the four characters of the
account_ID to differentiate accounts and to provide an
abbreviated description of the account function.
For example:
• A department, such as finance (FIN) or marketing (MKT)
• A job function, such as general use (G), update (U), or batch
processing (B).
A complete account ID might resemble one of the following:
FINB or MKTU
Note: Although more characters are allowed, using a fourcharacter account_ID maintains application compatibility and
helps prevent the overall account string from exceeding the 30
character limit when account string expansion takes place.
174
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Working with Profiles
Element
Description
Account String Expansion (ASE) Variables
Teradata Database tags the session with information specified by the ASE variables for later use in
management of database sessions. Each ASE variable expands to the number of characters needed to
express the related information. The 30 character string limit is enforced against the expanded form.
Specification of the ASE variables shown below is optional, but recommended. Other variables are
available. For information, see Database Administration.
&S
&D
&H
The ampersand (&) designates an account string expansion
(ASE) variable. Teradata Database automatically replaces these
variables with actual values upon opening the session. You can
use any or all of the following:
• &S = the session number
• &D = the date
• &H = the time
Determining the Account for a User Session
The system determines the account for a user when the user logs on as follows:
•
If the user is assigned only one account, the logon uses that account by default.
•
If the user is assigned multiple accounts and the default account (the first listed in the
operant user or profile definition) is appropriate for the session, the logon need not
contain the account string.
•
If the user has multiple accounts and does not want to use the default, the logon string can
specify another assigned account.
•
During a session, the user can submit a SET SESSION ACCOUNT statement to change the
session to another assigned account.
•
If the user has no account assignment, the session defaults to the first account listed for the
owning user or database. Such a use of default owner accounts is not recommended.
Working with Profiles
About Profiles
You can create profiles to define resource parameters for groups of users with similar needs
instead of defining them for each individual user. Then list the profile in a CREATE or
MODIFY USER statement to establish membership in a profile for each user.
Profiles can be based on the primary user types such as those shown in “About User
Requirements” on page 171, or other factors that group users according to database resource
requirements.
Teradata Data Warehouse Appliance 2690 Implementation Guide
175
Chapter 10: Setting Up Users
Working with Profiles
Use profiles to specify parameters such as:
•
Permanent and spool space allocations
•
User account(s)
•
Password control parameters
•
Default database assignment
Creating Profiles
1
Start Teradata Administrator and log on as user DBADMIN.
2
From the main screen, click the Preview Mode button
generated SQL.
3
Click Tools>Create>Profile.
4
In the Profiles screen, enter values for the profile parameters.
a
to allow future display of
In the Profile Name dialog box, enter a unique name for the profile.
Recommendation:
b
•
The profile name can include such things as the user type or user department to
identify its function. For example, GenUser_Profile or Finance_Profile.
•
Consolidate user requirements where possible to avoid the unnecessary
proliferation of profiles.
Click the General tab. Specify values for the following fields or controls.
Note: Profile values supersede corresponding values in a CREATE USER statement.
Field or Control
Description
Account
The database uses accounts for user job tracking and to prioritize requests.
Recommendation: Enter one or more account strings in accordance with
the format shown in “Working with User Accounts” on page 173.
If you assign more than one account string to a profile, enclose each string
in apostrophes, separate the strings with commas and enclose the complete
specification in parentheses, for example:
(‘$M0+accl&S&D&H’,‘$L0+accr&S&D&H’, ‘$R0+acc51’)
Note: There is a 30 character limit on each account string, and that limit
includes the expanded form of the ASE variables in the string.
Default Database
Optional. The database the user is most likely to access.
If no name is specified, the system uses the name specified in the user
definition (CREATE USER statement).
Recommendation: Specify the default database at the user level, rather than
in the profile, to allow for differences in user default database requirements.
176
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Working with Profiles
Field or Control
Description
Spool Space
This value limits the amount of space available for intermediate query
results or formatted answer sets to queries and volatile tables. Spool space
for a user is shared among the queries that user is executing concurrently.
The system borrows spool space for a user from unused permanent space in
the system.
Recommendation: Spool space requirements in a profile depend on the
activities of member users. Begin by specifying spool space in bytes
according to the following percentages of the total perm space allocation for
the Spool_Reserve database created in Chapter 5: “Setting up
Administrative Users.”
• General users: 5%
• Update users: 10%
• Batch users: 10%
• Assistant administrative users: 10%
• Database programmers: 10%
Periodically monitor usage patterns as shown in “Identifying and
Correcting Space Problems” on page 221, and modify spool space
assignments when required using the MODIFY PROFILE statement.
Spool space can also be specified as part of a CREATE USER statement or
modified as part of a MODIFY USER statement.
Note: Profile members that do not require permanent space must still be
allocated a small amount of spool space in the profile, for example, 1 MB.
Temporary Space
Not applicable. Required only when using global temporary tables and
other advanced features.
Recommendation: Temporary space is not normally needed. If necessary,
you can add a temporary space specification later with a MODIFY
PROFILE statement.
c
Click the Password tab to display the nine password control parameters.
Optional. The control parameters allow you to apply different settings in the profile
than are in the global default settings created in DBC.SysSecDefaults, as part of step 2
in “Setting Up the Database Administrator User” on page 87.
Recommendation: Do not reset any password control parameter values in a profile
unless the profile members cannot use the system defaults. For each profile password
control that you change from the global value, enter the new value in the box to the
right of the control name.
d
Do not use the Users in Profile dialog box at this time. You can specify profile
membership as follows:
•
Assign a profile to each user as part of “Working with Database Users.”
or
•
After creating users, use a MODIFY PROFILE statement to include member users.
Teradata Data Warehouse Appliance 2690 Implementation Guide
177
Chapter 10: Setting Up Users
Working with Profiles
e
Click the Create button to create the profile. The Query Window displays a generated
CREATE PROFILE statement similar to the following:
CREATE PROFILE profile_name AS
ACCOUNT = (‘account_str1’,’account_str2’)
DEFAULT DATABASE = database_name,
SPOOL = spool_space,
PASSWORD =
(EXPIRE = n_days,
MAXLOGONATTEMPTS = attempts,
LOCKEDUSEREXPIRE = n_minutes)
5
f
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
g
Close the Query Window and the Profiles dialog box.
Close Teradata Administrator or go on to Working with Database Users.
Reference Information
For Step...
Information on...
Is available in...
4
syntax and options for the
CREATE PROFILE statement
SQL Data Definition Language Syntax and
Examples
4b
using accounts to enforce session
priorities
• “Using Performance Groups to Manage Job
Priorities” on page 230.
• “Managing the Database with Teradata
Workload Management” on page 234.
• Database Administration
Adding account string expansion
variables to an account string
Database Administration.
guidelines for determining user
space requirements
Database Administration
information on monitoring and
reallocating space
“About Space Management” on page 217
global temporary tables
Database Design
password control options
Security Administration
4c
178
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Working with Database Users
Working with Database Users
About Users
This task creates individual database users, including lower level administrators, database
programmers and other privileged users, and database end-users.
Creating Users
1
Start Teradata Administrator and log on as user DBADMIN.
Note: This procedure creates users individually. To automate the creation of users by using
BTEQ scripts, see “Using BTEQ Scripts to Create Database Objects” on page 123.
2
From the main screen, click the Preview Mode button
generated SQL.
3
Do the following to create a user:
to allow future display of
a
Click Tools>Create>User.
b
In the Create User dialog, specify the values for the required fields and controls.
Field or Control
Explanation
User Name
Required. The name of an individual Teradata Database user.
Each database user should be uniquely identified for accurate logging. Do
not allow users to share a username for accessing the database.
Note: The username must conform to the rules for SQL object names.
Owner
Required. The name of the database or user that owns the space in which
the user is created.
Recommendation: DBADMIN. All users should be created in space
owned by the database administrator.
Password
Required. A temporary password. The user is prompted to change the
temporary password to a permanent, private password at first logon.
Permanent Space
May be required. Space in bytes that can be used to contain objects the
user creates or owns. Permanent space is required for those users that
create and store space-consuming objects.
Recommendation: Base the permanent space specification on user needs.
•
•
•
•
•
General users: Not required.
Update users: Required if users create and store objects.
Batch users: Required if users create and store objects.
Assistant administrators: Required if users create and store objects.
Database programmers: Required to create and store objects.
Teradata Data Warehouse Appliance 2690 Implementation Guide
179
Chapter 10: Setting Up Users
Working with Database Users
Field or Control
Explanation
Spool Space
Optional. Specifies the limit to the amount of space in bytes available for
temporary process constructs such as intermediate query results or
formatted answer sets to queries and volatile tables. Spool space for a user
is shared among the queries that user is executing concurrently.
The system borrows user spool space from any unused permanent space
found on the system.
The spool space specification in a profile takes precedence over spool
space specified in a CREATE USER statement.
Recommendation: Specify spool space as part of a profile unless the user
requires special spool considerations.
If you do enter a value for an individual user, specify approximately 20%
of the perm space available to the largest database the user will query.
Temporary Space
Not applicable. Required only when using global temporary tables and
other advanced features.
Specifying temporary space requires that you develop a strategy for use of
the advanced features that need such space. If necessary, you can add a
temporary space specification later with a MODIFY USER or MODIFY
PROFILE statement.
Account
Optional. You can set up user account information to form the basis of
various user management options.
Recommendation: Do not specify accounts at the user level, unless the
user requires unique system priorities. Instead name a profile in the
Profile parameter that contains the needed account(s). For information,
see “Working with Profiles” on page 175.
Note: If a user is a member of a profile that specifies one or more
accounts, the profile account assignment supersedes and
invalidates all account assignments specified in the user definition.
Default Database
Optional. Identifies the database that owns the space in which the
Teradata Database stores or searches for new or target objects in an SQL
query, unless a different database is specified in the query.
Note: Users can use the DATABASE statement to establish a new default
database for the current session.
Recommendation: Specify the database most often accessed by the user.
• General users: Specify a read-only Views database. If restrictions are
necessary, use role privileges to allow access to particular views.
• Update users: Specify either a read-only Views or an updatable Views
database, depending on where the user normally works.
• Batch users: Specify the Tables_Database, where batch operations take
place.
• Assistant administrators: Specify DBADMIN.
• Database programmers: Specify the name of the development
database.
180
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Working with Database Users
Field or Control
Explanation
Profile Name
Optional. Gives the user membership in the named profile.
For syntax elements that appear in both the CREATE USER statement for
a user, and in a profile in which the user is a member, the profile values
take precedence.
A user can be a member of only one profile.
Recommendation: Specify profile membership for all users. Select from
the drop-down list and highlight the needed profile.
Default Role
Identifies the default role used for determining user privileges in the
database for the current session. This is usually the role associated with
the activities performed most frequently by the user.
Note: The user can employ the SET ROLE statement at the beginning of a
session or transaction to change from the default role to another role. The
SET ROLE ALL statement allows access to all roles of which the user is a
member.
Recommendation: You may specify a default role later after you have
created the user and the roles. See “Defining the Default Role for a User”
on page 189. Note that you must specify a default role even if the user is a
member of only one role.
Default Journal
Optional.
Startup String
Recommendation: Do not use for initial database implementation.
Before Journal
After Journal
FALLBACK
Optional. Specification of FALLBACK automatically creates a duplicate of
each table stored in the user space, in addition to the duplicates already
created by disk mirroring. The system reverts to the FALLBACK tables in
the event of a failure.
Recommendation: Specify FALLBACK only for individual missioncritical tables or tables so large that their size prevents timely backup to
tape or external disk.
Collation
Time Zone
Default Date Form
Default Character
Set
c
Optional. Database default values that apply to all users are already set as
part of system installation and configuration.
Recommendation: Do not change the default values for a user unless the
default value is not applicable.
Note: All users must use the same collation value.
Click the Create button. The Query Window displays the generated CREATE USER
statement, similar to the following:
CREATE USER "GenUser1" FROM "DBADMIN"
AS PERM = 0
PASSWORD = "temp123"
STARTUP = ''
DEFAULT DATABASE = "Personnel_Views"
NO FALLBACK
Teradata Data Warehouse Appliance 2690 Implementation Guide
181
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
NO BEFORE JOURNAL
NO AFTER JOURNAL
PROFILE=”GenUser_Profile”
4
d
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
e
Close the Query Window and the Create User dialog box.
Log off Teradata Administrator or go on to “Using Roles to Manage User Privileges” on
page 182.
Reference Information
For Step...
Information on...
Is available in...
3
syntax and options for the CREATE
USER statement
SQL Data Definition Language Syntax and
Examples
assigning permanent and spool space
Database Administration
the creation and use of accounts
“Working with User Accounts” on page 173
Using Roles to Manage User Privileges
Do the following to setup roles to manage user privileges:
1
Create roles, as shown in “Creating User Roles.”
2
Grant privileges to each role, as shown in “Granting Privileges to a Role.”
3
Grant role membership to users, as shown in “Granting User Membership in a Role.”
Note: Some privileges cannot be granted to a role. You must grant those privileges directly to
a user. For information, see “Granting Privileges Directly to Users” on page 190.
User Types and Minimum Required Privileges
The following table describes the minimal privileges required by the three basic user types.
User Type
Privilege Requirements
General
Database end-users who typically read data and execute macros in a read-only
Views database created in Chapter 5, “Working with Views” on page 117.
Assign the following privileges on a read-only Views database to all General users:
• EXECUTE
• SELECT
The read-only Views database must have privileges on the Tables_Database, as
shown in “Working with Table Access Privileges for Views” on page 105.
182
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
User Type
Privilege Requirements
Update
Privileged database users who update data generally require the following
privileges:
Privileges required on a read-only Views database:
• EXECUTE
• SELECT
• CREATE VIEW and DROP VIEW
• CREATE MACRO and DROP MACRO
Privileges required on an updatable Views database:
• EXECUTE
• SELECT
• INSERT, UPDATE, and DELETE
• EXECUTE PROCEDURE
• EXECUTE FUNCTION
• CREATE VIEW and DROP VIEW
• CREATE MACRO and DROP MACRO
Additional recommended privileges on an updatable Views database for database
programmers:
• SHOW
• ALTER, CREATE, and DROP PROCEDURE
• ALTER, CREATE, and DROP FUNCTION
• ALTER and CREATE EXTERNAL PROCEDURE
• CREATE TRIGGER and DROP TRIGGER
To provide update capability on views, you must grant the updatable Views
database SELECT, INSERT, UPDATE, DELETE WITH GRANT OPTION
privileges on the referenced tables in the Tables_Database, as shown in “Working
with Table Access Privileges for Views” on page 105.
Batch
Data movers, who typically perform batch-level functions, such as:
• Batch data load, update, and export operations.
• Data backup, archive, and restore operations, including creating and deleting
staging tables.
Batch users must have the following privileges on the Tables_Database:
•
•
•
•
•
Assistant
Administrators
SELECT
INSERT, UPDATE, DELETE
DUMP and RESTORE
CHECKPOINT
CREATE TABLE and DROP TABLE
If you need one or more assistant administrators to help share administrative
duties, they may require the same privileges as those granted to DBADMIN, or a
subset of those privileges. Use the procedure shown in Chapter 4, “Setting Up the
Database Administrator User” on page 87 and “Granting Database Privileges to
User DBADMIN” on page 91 to create assistant administrators and grant the
privileges they need.
Teradata Data Warehouse Appliance 2690 Implementation Guide
183
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
User Type
Privilege Requirements
Database
Programmers
Database programmers may require administrator-level privileges within the
development database to allow them to create and test database objects.
Administrators can then deploy the objects to the production database.
Types of Privileges
You can explicitly grant database privileges to users, roles, or databases. Users also gain other
privileges without a formal grant. Before you decide which privileges to explicitly grant, make
sure you understand the privileges users receive by other means.
Privilege
Description
Implicit Privileges
Ownership
Users that own perm space have certain implicit (ownership)
privileges on any object contained in the space they own, even if they
did not create the object.
Note: You can transfer ownership using the GIVE statement.
Explicit privileges
Automatic
When a user creates a database object, Teradata Database automatically grants
privileges to:
• The creator of the object
• A newly created user or database
GRANT
You can grant privileges:
• Directly to a user or database
• To a role, then GRANT membership in the role to one or more users
• To an external role, then map the external role to one or more groups of
directory users
Inherited
Privileges that a user acquires indirectly.
• All users inherit the privileges of the system-generated user, PUBLIC, a
role-like collection of privileges available by default, whether or not they
have any other privileges. You can grant additional privileges to PUBLIC.
• A user inherits all the privileges granted to each role of which the user is a
member.
• Directory users inherit the privileges of the database users and external
roles to which they are mapped.
Note: The system logs automatic and explicit privileges in exactly the same way, and are
indistinguishable as to how they were acquired. All privileges except implicit privileges are
stored in the data dictionary in the DBC.AccessRights table, by each user.
For a detailed discussion of privileges, see “Teradata Database User Privileges” in Chapter 5:
“Creating Users and Granting Privileges” in Security Administration.
184
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Privileges That Must Be Explicitly Granted
Some privileges cannot be acquired by indirect means and must be explicitly granted to a user,
database, or role. For information, see “Privileges that Must Be Explicitly Granted” in Security
Administration.
Creating User Roles
1
Start Teradata Administrator and log on as user DBADMIN.
2
On the main screen, click the Preview Mode button
generated SQL.
3
Click Tools>Create>Role.
4
In the Roles dialog, use the Role Name field to specify a unique role name. The role name
should also provide some indication of the role function or the group of users to which it
applies, for instance:
5
•
FinanceUser_Role
•
Update_Role
to allow future display of
Click the Create button. The Query Window displays the generated CREATE ROLE
statement:
CREATE ROLE role_name
6
In the Query Window, click the Run Query
button. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
7
Close the Query Window and the Roles dialog box.
8
Repeat this procedure to create the needed roles.
9
Log off Teradata Administrator or go on to “Granting Privileges to a Role.”.
Granting Privileges to a Role
Use the GRANT statement to grant privileges to the roles necessary to serve the basic user
types. A GRANT statement takes the following basic form:
GRANT privilege
ON database_object_name
TO role_name
1
Start Teradata Administrator and log on as user DBADMIN.
2
From the main screen, click the Preview Mode button
generated SQL.
3
Grant privileges to each role as follows:
to allow future display of
a
Click Tools>Grant/Revoke>Object Rights.
b
In the Grant/Revoke Objects dialog, specify values for the following:
Teradata Data Warehouse Appliance 2690 Implementation Guide
185
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Fields and Controls
Explanation
Database Name
Required.
• To grant privileges on an entire database, specify the name of the
database.
• To grant privileges on an object, specify the parent database that
contains the object.
Recommendation: When specifying privileges for:
• General users, select a read-only Views database.
• Update users, select a read-only Views database or an updatable Views
database.
• Batch users, select the Tables_Database.
• Administrative users, select DBADMIN.
• Database programmers, select a Development database.
Object Type
Required.
Specify the type of database object on which privileges are being granted.
For example:
• To grant privileges on the Tables_Database, specify Database.
• To grant privileges on the tables located in the Tables_Database,
specify Table.
Recommendation: Always grant privileges at the highest level that is
appropriate, while observing security concerns and user “need to know.”
Objects
Required when objects are displayed.
If the Object Type is Database, this field is blank and not required.
Otherwise, the Objects field displays all of the database objects of the
object type contained in the named database.
For example, if Database Name is Tables_Database and Object Type is
Table, this field displays all of the tables contained in the
Tables_Database.
Select the specific database object on which privileges are being granted.
To/From User
Not applicable for granting privileges to roles.
Role
Required. The role to which the specified privileges are granted.
Select the name of a previously created role from the displayed list.
Public
Optional.
Checking the Public box grants the specified privileges to PUBLIC, a
group of rights accessible by any user with logon privileges, even if no
other privileges have been granted.
Recommendation: Do not grant additional privileges to PUBLIC at this
time.
186
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Fields and Controls
Explanation
Normal
Required. Specify the privileges by checking the boxes, based on the
guidelines in “User Types and Minimum Required Privileges” on
page 182.
Create
Drop
Recommendation: Consider the privileges that the user may get without
formal granting, as shown in “Types of Privileges” on page 184, before
deciding on what privileges to grant.
All
Optional. Do not use for roles.
Grants all privileges that apply on the database object. This box is usually
used only for the master administrator, DBADMIN.
Dictionary
Optional. Grants administrative privileges on data dictionary tables.
Access
Optional.
Provides basic SELECT and EXECUTE privileges on the specified object.
All But
Optional.
When the All But box is checked, role members receive all privileges
except those checked in the Normal, Create, and Drop sections.
Not all privileges need to be granted using roles. It may be more efficient to grant some
specialized privileges directly to a user, rather than creating a role with a membership
of one.
Note: Any user can grant privileges on any database object it owns to any other user or
role, excluding the CREATE and DROP privileges, which are not ownership privileges.
c
Click the Grant button. The Query Window displays the generated GRANT statement,
for example:
GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, DUMP, RESTORE,
CHECKPOINT, CREATE TABLE, DROP TABLE ON "Tables_Database" TO
"Role_BatchUser_2"
d
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
e
Close the Query Window and the Grant/Revoke Objects dialog box.
4
Repeat this procedure to grant privileges to all roles.
5
Close Teradata Administrator or go to “Granting User Membership in a Role.”
Teradata Data Warehouse Appliance 2690 Implementation Guide
187
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Reference Information
For Step...
Information on...
Is available in...
3
syntax and options for the GRANT
(SQL Form) statement
SQL Data Control Language
using roles to manage user access
Security Administration
Granting User Membership in a Role
After creating database users, grant them membership in one or more roles to provide the
required database access privileges.
1
Start Teradata Administrator and log on as user DBADMIN.
2
On the main screen, click the Preview Mode button
generated SQL.
3
Click Tools>Create>Role.
4
In the Roles dialog, select a role from the Role Name drop-down menu.
5
Click the Users tab.
6
Select all users that will be members of the selected role, and click Add.
7
The Query Window will display a GRANT statement similar to:
to allow future display of
Grant "Role_1" To "GenUser1";
8
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
9
Close the Query Window and the Roles dialog box.
10 Repeat this procedure for each role to which a user requires membership.
11 Log off Teradata Administrator or go to “Defining the Default Role for a User.”
Reference Information
188
For Step...
Information on...
Is available in...
1
syntax and options for the
CREATE ROLE statement
SQL Data Definition Language Syntax and
Examples
using roles to manage user access
Security Administration
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
For Step...
Information on...
Is available in...
2
syntax and options for the GRANT
(SQL form) statement
SQL Data Control Language
database privileges, including
those conferred by object
ownership
3
syntax and options for GRANT
(Role form)
Defining the Default Role for a User
To ensure that role privileges are available to users at log on, you must define a default role for
each user that is a member of one or more roles. If you do not specify a default role, the user
must employ the SET ROLE statement to select the operant role. For example:
SET ROLE role_name;
or
SET ROLE ALL;
You can also use the SET ROLE statement to change from one role to another role within a
session.
To ensure that the user is operating with the appropriate role, specify the default role for a user
as follows:
1
Start Teradata Administrator and log on as user DBADMIN.
2
On the main screen, click the Preview Mode button
generated SQL.
3
Click the + next to DBADMIN to display the list of users.
4
Select the user you want to modify.
5
Click Tools>Modify User.
6
In the Modify User dialog, click the Default Role drop-down menu and select a default role.
You can optionally select All Roles, which will allow access to all roles of which the user is a
member.
7
Click the Modify button. The Query Window displays the generated MODIFY USER
statement, for example:
to allow future display of
MODIFY USER "GenUser1" AS
STARTUP = ''
DEFAULT DATABASE = "Personnel_Views"
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
COLLATION = HOST
DEFAULT CHARACTER SET LATIN
DATEFORM=INTEGERDATE
Teradata Data Warehouse Appliance 2690 Implementation Guide
189
Chapter 10: Setting Up Users
Granting Privileges Directly to Users
TIME ZONE=NULL
DEFAULT ROLE="Role_GenUser_2"
8
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
9
Close the Query Window and the Modify User dialog box.
10 Repeat this procedure to specify the default role for each user who is a member of a role.
11 Log off Teradata Administrator or go on to “Granting Privileges Directly to Users.”
Reference Information
For Step...
Information on...
Is available in...
1
syntax and options for the SET ROLE
statement
SQL Data Definition Language Syntax and
Examples
7
syntax and options for the MODIFY
USER statement, including the default
role
SQL Data Definition Language Syntax and
Examples
using roles to manage user access
Security Administration
Granting Privileges Directly to Users
Some privileges cannot or should not be granted to roles, but should instead be granted
directly to users.
•
System-level privileges that cannot be granted to a role, as shown in “Granting Database
Privileges to User DBADMIN” on page 91.
Note: System-level privileges are normally used by administrators and should not be
granted to other users.
•
Object-level privileges that apply to too few users to require creation of a role.
Note: A user automatically has the privilege to grant most privileges on any database object
the user owns to any other user or role. This excludes CREATE and DROP privileges, which
are not automatic ownership privileges. The CREATE and DROP privileges must be granted
directly to a user, and must include the WITH GRANT OPTION clause, before that user can
grant these privileges to others. For information on ownership privileges, see Security
Administration.
Prerequisites
You can only grant privileges to users that already exist in the database. For information on
creating users, see “Working with Database Users” on page 179.
190
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Granting Privileges Directly to Users
The Sys_Calendar database and Calendar view must exist. They are normally created as part of
system installation by running the DIPALL script.
Granting Privileges on Sys_Calendar to All Users
Sys_Calendar is a system database used to contain the Sys_Calendar.CalDates table and
Sys_Calendar.Calendar view. The Calendar view is a user-accessible tool for date arithmetic. It
permits easy specification of arithmetic expressions and aggregation, and is particularly useful
when requesting values aggregated by weeks, months, year-to-date, years, and so on. You can
use the Calendar view to get attributes for any date between the years 1900 and 2100, such as
which day of the week or which week of the month a date occurs.
Use the following procedure to grant SELECT privilege on Sys_Calendar to all Teradata
Database users.
1
Start Teradata SQL Assistant and log on as DBADMIN.
2
Enter the following statement in the main query window:
GRANT SELECT ON Sys_Calendar TO PUBLIC
3
Click the Execute button
4
Close Teradata SQL Assistant.
to run the query.
Reference Information
For Step...
Information on...
Is available in...
All
the Calendar view
Data Dictionary
Granting Privileges to a User
1
Start Teradata Administrator and log on as DBADMIN.
2
From the main screen, click the Preview Mode button
generated SQL.
3
Click Tools>Grant/Revoke>Object Rights.
4
In the Grant/Revoke Objects dialog, specify the following:
to allow future display of
•
Use the Database Name, Object Type, and Objects fields to identify the database object
which the user will receive privileges on.
•
In the To/From User tab, select the user who will receive the specified privileges.
•
In the Normal, Create, or Drop sections, check the privileges the user will receive.
For details, see “Granting Database Privileges to User DBADMIN” on page 91.
Teradata Data Warehouse Appliance 2690 Implementation Guide
191
Chapter 10: Setting Up Users
Checkpoint
Click the Grant button. The Query Window displays the generated GRANT statement
similar to:
5
GRANT privilege
ON database_object_name
TO username;
where
•
The ON clause is based on the values of the Database Name, Object Type, and Objects
fields.
•
The TO clause is based on the user selected from the To/From User tab.
6
In the Query Window, click the Run Query button
. A Query Complete message
appears in the bottom left corner of the main window when the query executes.
7
Close the Query Window and the Grant/Revoke Objects dialog box.
8
Log off Teradata Administrator.
Reference Information
For Step...
Information on...
Is available in...
5
syntax and options for the GRANT
(SQL form) statement
SQL Data Control Language
database privileges, including those
conferred by object ownership
Security Administration
Checkpoint
Before leaving Chapter 10: “Setting Up Users,” make sure that:
√
192
Result
Reference
You have assessed database user needs and
developed a user management strategy.
“About User Requirements” on
page 171.
You have created accounts for all user categories
“Working with User Accounts” on
page 173
Profiles define resource parameters for groups of
users with similar needs.
“Working with Profiles” on page 175.
Individual database users, including
administrators and end users, have been created.
“Working with Database Users” on
page 179.
Roles are created in your database, each role has
privileges, and users have been granted role
membership.
“Using Roles to Manage User
Privileges” on page 182.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 10: Setting Up Users
Checkpoint
√
Result
Reference
Some users, such as administrators and those
who need uncommon object-level privileges,
have had privileges granted to them directly.
“Granting Privileges Directly to Users”
on page 190.
If you do not have these results, return to the section in the Reference column and review that
procedure.
Teradata Data Warehouse Appliance 2690 Implementation Guide
193
Chapter 10: Setting Up Users
Checkpoint
194
Teradata Data Warehouse Appliance 2690 Implementation Guide
SECTION 3
Database Administration
Teradata Data Warehouse Appliance 2690 Implementation Guide
195
Section 3: Database Administration
196
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 11
Monitoring User Activity
About Access Logging
You can log user activity in the database, and then audit the logs to identify:
•
User logon frequency
•
Database objects accessed
•
Privileges checked
•
Failed access attempts
•
Possible unauthorized activities
Default Access Logging
By default, Teradata Database records all permanent user attempts to log on and off Teradata
Database in the Event Log.
Common Access Logging Requirements
A common rationale for logging and auditing user access to the database is the Payment Card
Industry Data Security Standard (PCI-DSS), which requires that all retailers, financial
institutions, and payment processors that store information on credit card holders must
provide audit trails that allow reconstruction of all instances of the following events:
•
Attempts to access cardholder data
•
Actions of any type taken by any individual with root or administrative privileges
•
Invalid access attempts
•
Creation and deletion of system-level objects
•
Initialization of the audit logs (use of the BEGIN/END LOGGING statement)
•
Attempts to access audit trails
•
Use of identification and authentication mechanisms
The example logging and auditing procedures in the sections that follow are based on the PCIDSS requirements, but they can be used to monitor access to any sensitive data.
Note: The procedures shown in the following sections are provided only as examples, and do
not in themselves guarantee compliance with PCI-DSS requirements.
For additional information on logging and auditing options, see Security Administration.
Teradata Data Warehouse Appliance 2690 Implementation Guide
197
Chapter 11: Monitoring User Activity
Setting Up Access Logging
Setting Up Access Logging
Running the DIPACC Script
The DBC.AccLogRule macro must exist in the database before initiating access logging. You
can create this macro with the DIPACC script.
1
Log on to the control node as shown in “Logging on to the Control Node” on page 239.
2
Open a cnsterm window as shown in steps 1 and 2 of “Using cnsterm to Run a Database
Utility” on page 240.
3
At the Input Supervisor Command prompt, start the DIP utility.
> start dip
4
Hold the Ctrl key while pressing the C key to exit the Supervisor Window.
5
At the Linux command prompt start cnsterm again, this time specifying the application
window in which the DIP utility is running.
# cnsterm 1
6
At the prompt on cnsterm screen 1, enter the DIP number for the DIPACC script:
> 18
7
The system returns a message similar to the following:
Executing DIPACC at Wed Sep 16 15:54:06 2009
Please wait...
DIPACC is complete at Wed Sep 16 15:54:06 2009
Please review the results in /var/opt/teradata/tdtemp/dip18.txt on
node 4- 9
Would you like to execute another DIP script (Y/N)?
8
Enter N at the prompt to exit DIP.
9
Close the Client Connection window.
10 Close the Teradata Administration Workstation window.
About the BEGIN LOGGING Statement
You can enable access logging using the BEGIN LOGGING statement.
The basic form of the BEGIN LOGGING statement is:
BEGIN LOGGING ON frequency operation BY username ON object_name ;
where:
Syntax Element
Description
frequency
The frequency of logging during a session.
Valid specifications: FIRST, LAST, FIRST AND LAST, or EACH
operation
198
The action or comma-separated list of actions which, if present in a
user request, triggers logging.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 11: Monitoring User Activity
Setting Up Access Logging
Syntax Element
Description
username
The name of the user, or comma-separated list of users, for which the
system logs activity.
object_name
The name of a database object which, if present in a request, triggers
logging.
Note: BEGIN LOGGING parameters are optional. The absence of some parameters causes the
system to use default values. For a detailed description of BEGIN LOGGING syntax and
options, see SQL Data Definition Language: Syntax and Examples.
The BEGIN LOGGING statement also has differing effects depending on how subsequent user
queries reference the object of the logging rule when they access the database.
For example, the logging statement BEGIN LOGGING ON FIRST SELECT...ON
DatabaseA.Table1 has the following effects:
Query
Result
SELECT . . . FROM Table1
The system generates a log entry because the query
directly names the object that is subject to the
logging rule.
SELECT . . . FROM View1
The system does not generate a log entry for these
queries, even though they access Table1, because the
queries do not directly reference Table1.
(where View1 is a view of Table1)
EXECUTE MACRO1
(where Macro1 contains the statement
SELECT . . . FROM Table1)
Note: To log access of Table1 for these queries, you must
create logging rules that specify the view or macro.
Enabling Access Logging
The following procedure is based on the example requirements shown in “Common Access
Logging Requirements” on page 197.
1
Start Teradata Administrator and log on as user DBADMIN.
2
On the main screen, click the Preview Mode button
SQL.
3
Initiate logging on tables or views that contains sensitive data, such as cardholder data.
to enable display of generated
a
From the main window, click Tools>Access Logging.
b
The Access Logging screen contains three check boxes labeled All. Two boxes are
already checked by default. Uncheck the All boxes to enable display of the option list.
c
Specify values for the following fields:
Teradata Data Warehouse Appliance 2690 Implementation Guide
199
Chapter 11: Monitoring User Activity
Setting Up Access Logging
Field
Description
On Database
The name of the database that owns the object that contains the sensitive
data.
Select the containing database from the drop down list.
Object Type
The type of object that contains the sensitive data.
Select Table or View from the drop down list to identify the type of object that
contains the sensitive data.
Object
The specific object that contains the sensitive data
Select the name of the specific table or view from the drop down list.
By User
The name of the user(s) for which logging is required.
Check the All box. Access by any user must be auditable. All is highlighted in
the By User field.
Denials
Checking this box logs any denial of access to the object.
Recommendation: Not required. All denials are logged as part of step 5.
With SQL
Optional. Checking this box logs the SQL submitted against the object.
Note: Logging SQL may consume a large amount of log space. Do not check
this box except as needed for detailed investigation of an individual user.
First
Checking one of these boxes indicates when the logging is to be performed.
Last
Recommendation: Check Each to conform to the requirement for logging all
administrator activity.
First & Last
Each
Normal field
Lists the normal privileges applicable to the object.
Recommendation: Check all the active (not grayed out) privileges listed
except Checkpoint.
Create field
Lists the create privileges applicable to the object.
Recommendation: Check all the active (not grayed out) privileges listed.
Drop field
Lists the drop privileges applicable to the object.
Recommendation: Check all the active (not grayed out) privileges listed.
Groups field
Checking items in the Groups field automatically creates multiple logging
rules.
Recommendation: Do not check any items in this field.
d
Click the Begin Log button.
The Query window appears and displays the generated BEGIN LOGGING statement.
BEGIN LOGGING DENIALS ON EACH SELECT, INSERT, UPDATE, DELETE,
STATISTICS, INDEX, REFERENCES, DUMP, RESTORE, SHOW, GRANT, CREATE
TRIGGER, DROP TABLE, DROP TRIGGER ON Table
"Tables_Database"."Table_Name"
200
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 11: Monitoring User Activity
Setting Up Access Logging
e
From the Query window, click the Run Query button
f
You can optionally display the list of access logging rules at any time as follows:
i
Close the Access Logging window.
ii
On the main menu deselect the Preview Mode button
display.
.
to suppress the SQL
iii On the main window, click Tools>Access Logging.
iv In the Access Logging window, click the Display button to display the logging rules
created by the previous steps.
g
Repeat step 1 through step 3 for each table or view that contains sensitive data. As an
alternative to repeating the entire procedure, you can do the following:
i
Copy the SQL for the initial logging statement.
ii
Open a query window by clicking the Query button
at the bottom of the left
hand menu. This opens a Teradata SQL Assistant query window, which can execute
multiple SQL statements.
iii Paste in the SQL and replicate it for each table or view that contains sensitive data,
customizing each statement copy for a specific object.
iv Click the Run Query button
h
4
to execute the SQL statements.
Close the Query window.
Initiate logging of any action taken by all users with administrative privileges as follows:
a
From the Access Logging window, uncheck the All boxes to display the lists of options.
b
Specify values for the following fields:
Field
Description
On Database
The name of the owner of the object that contains the sensitive data.
Recommendation: Check the All box to capture all administrator activity.
Object Type
The type of object that contains the sensitive data.
Not required because the All box is checked in the On Database field.
Object
The specific object that contains the sensitive data
Not required because the All box is checked in the On Database field.
Teradata Data Warehouse Appliance 2690 Implementation Guide
201
Chapter 11: Monitoring User Activity
Setting Up Access Logging
Field
Description
By User
The name of the user(s) for which logging is required.
Recommendation: Select all users that have administrative privileges from the
By User field.
Denials
Checking this box logs any denial of access to the object.
Recommendation: Not required. All denials are logged as part of step 5.
With SQL
Optional. Checking this box logs the SQL submitted against the object.
Note: Logging SQL may consume a large amount of log space. Do not check
this box except as needed for detailed investigation of a specific user.
First
Last
First & Last
Each
Checking one of these boxes indicates when the logging is to be performed.
Normal field
Not required. Specification of individual privileges is checked automatically
when All is checked in the Groups field.
Create field
Recommendation: Check Each to log all administrator activity.
Drop field
Groups field
Checking items in the Groups field creates multiple logging rules.
Recommendation: Check All to monitor all privilege checks for administrators.
c
Click the Begin Log button.
The Query window appears and displays the generated BEGIN LOGGING statement.
BEGIN LOGGING DENIALS ON EACH EXECUTE, SELECT, INSERT, UPDATE,
DELETE, STATISTICS, INDEX, REFERENCES, DUMP, RESTORE, CHECKPOINT,
SHOW, EXECUTE PROCEDURE, ALTER PROCEDURE, UDTUSAGE, UDTTYPE, GRANT,
UDTMETHOD, EXECUTE FUNCTION, ALTER FUNCTION, ALTER EXTERNAL
PROCEDURE, CREATE OWNER PROCEDURE, CREATE TABLE, CREATE VIEW,
CREATE MACRO, CREATE DATABASE, CREATE USER, CREATE TRIGGER, CREATE
PROCEDURE, CREATE PROFILE, CREATE ROLE, CREATE FUNCTION, CREATE
EXTERNAL PROCEDURE, CREATE AUTHORIZATION, DROP TABLE, DROP VIEW,
DROP MACRO, DROP DATABASE, DROP USER, DROP TRIGGER, DROP PROCEDURE,
DROP PROFILE, DROP ROLE, DROP FUNCTION, DROP AUTHORIZATION BY
"DBADMIN","DBC","admin1","admin2"
202
d
From the Query window, click the Run Query button
e
Close the Query window.
.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 11: Monitoring User Activity
Setting Up Access Logging
5
Initiate logging of all invalid access attempts as follows:
a
Specify values for the following fields:
Field
Description
On
Database
The name of the owner of the object that contains the sensitive data.
Object Type
The type of object.
Recommendation: Check the All box (the default) to log invalid access attempts
on all databases and objects.
Not required because the All box is checked in the On Database field.
Object
The specific object.
Not required because the All box is checked in the On Database field.
By User
The name of the user(s) for which logging is required.
Recommendation: Check the All box above the By User field to log invalid access
attempts by all users.
Denials
Checking this box logs any denial of access to the object.
Recommendation: Check this box.
With SQL
Optional. Checking this box logs the SQL submitted against the object.
Note: Logging SQL may consume a large amount of log space. Do not check this
box except as needed for detailed investigation of a specific user.
First
Last
First & Last
Each
Checking one of these boxes indicates when the logging is to be performed.
Normal
field
Not required. Specification of individual privileges is checked automatically
when All is checked in the Groups field.
Recommendation: Check Each to log all access attempts.
Create field
Drop field
Groups
field
b
Checking items in the Groups field creates multiple logging rules.
Recommendation: Check All to monitor all privilege checks for administrators.
Click the Begin Log button. The Query window appears with the following SQL:
BEGIN LOGGING DENIALS ON EACH EXECUTE, SELECT, INSERT, UPDATE,
DELETE, STATISTICS, INDEX, REFERENCES, DUMP, RESTORE, CHECKPOINT,
SHOW, EXECUTE PROCEDURE, ALTER PROCEDURE, UDTUSAGE, UDTTYPE, GRANT,
UDTMETHOD, EXECUTE FUNCTION, ALTER FUNCTION, ALTER EXTERNAL
PROCEDURE, CREATE OWNER PROCEDURE, CREATE TABLE, CREATE VIEW,
CREATE MACRO, CREATE DATABASE, CREATE USER, CREATE TRIGGER, CREATE
PROCEDURE, CREATE PROFILE, CREATE ROLE, CREATE FUNCTION, CREATE
EXTERNAL PROCEDURE, CREATE AUTHORIZATION, DROP TABLE, DROP VIEW,
DROP MACRO, DROP DATABASE, DROP USER, DROP TRIGGER, DROP PROCEDURE,
DROP PROFILE, DROP ROLE, DROP FUNCTION, DROP AUTHORIZATION;
Teradata Data Warehouse Appliance 2690 Implementation Guide
203
Chapter 11: Monitoring User Activity
Setting Up Access Logging
6
c
From the Query window, click the Run Query button
d
Close the Query window.
.
Initiate logging of any query that creates or deletes a system level object, that is, in the
space directly owned by user dbc, as follows:
a
From the Access Logging window, uncheck the All boxes to display the options lists.
b
Specify values for the following fields:
Field
Description
On Database
The name of the owner of the object that contains the sensitive data.
Recommendation: Select DBC to specify the system-level database.
Object Type
The type of object that contains system-level objects.
Recommendation: Specify Database.
Object
Not required. The previous two fields already identify the top-level object.
By User
The name of the user(s) for which logging is required.
Recommendation: Check All in the box above the By User field to log creation
or deletion of system-level objects by all users.
Denials
Checking this box logs any denial of access to the object.
Recommendation: Not required. All denials are logged as part of step 5.
With SQL
Optional. Checking this box logs the SQL submitted against the object.
Note: Logging SQL may consume a large amount of log space. Do not check
this box except as needed for detailed investigation of a specific user.
First
Last
First & Last
Each
Checking one of these boxes indicates when the logging is performed.
Normal field
Not required. Specification of individual privileges is checked automatically
when All is checked in the Groups field.
Create field
Recommendation: Check Each to log attempts to create or delete system-level
objects.
Drop field
Groups field
Checking items in the Groups field creates multiple logging rules.
Recommendation: Check All to monitor all privilege checks on database DBC.
c
Click the Begin Log button.
BEGIN LOGGING ON EACH INDEX, REFERENCES, ALTER PROCEDURE, ALTER
FUNCTION, ALTER EXTERNAL PROCEDURE, CREATE OWNER PROCEDURE, CREATE
TABLE, CREATE VIEW, CREATE MACRO, CREATE DATABASE, CREATE USER,
CREATE TRIGGER, CREATE PROCEDURE, CREATE FUNCTION, CREATE EXTERNAL
PROCEDURE, CREATE AUTHORIZATION, DROP TABLE, DROP VIEW, DROP MACRO,
DROP DATABASE, DROP USER, DROP TRIGGER, DROP PROCEDURE, DROP
FUNCTION, DROP AUTHORIZATION ON Database "DBC"
204
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 11: Monitoring User Activity
Setting Up Access Logging
7
d
From the Query window, click the Run Query button
e
Close the Query window.
f
Close the Access Logging window.
.
Log the initialization of the audit logs.
a
On the main screen press the Query button
open SQL Assistant.
b
In the SQL Assistant Query window, enter the following SQL statement:
at the bottom of the left menu to
BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.AccLogRule;
c
8
Click the Run Query button
Initiate logging on all attempts to access audit trails.
a
Enter the following SQL statement in the SQL Assistant Query window.
BEGIN
BEGIN
BEGIN
BEGIN
BEGIN
b
9
.
LOGGING
LOGGING
LOGGING
LOGGING
LOGGING
ON
ON
ON
ON
ON
EACH
EACH
EACH
EACH
EACH
ALL
ALL
ALL
ALL
ALL
Click the Run Query button
ON
ON
ON
ON
ON
TABLE DBC.AccessLogTbl;
VIEW DBC.AccessLog;
VIEW DBC.DeleteAccessLog;
TABLE DBC.EventLog;
VIEW DBC.LogOnOff;
.
Close the Query Window and the Access Logging dialog box.
10 Log off Teradata Administrator or go on to “Auditing Database Activity Using DBC Log
Views.”
Reference Information
For step...
Information on...
Is available in...
All
the DIPACC script and the
DBC.AccLogRule macro
Utilities: Volume 1 (A-K)
security logging strategies; logging for
directory users and proxy users
Security Administration
optional specifications and syntax for
the BEGIN LOGGING statement
SQL Data Definition Language Syntax and
Examples
Teradata Data Warehouse Appliance 2690 Implementation Guide
205
Chapter 11: Monitoring User Activity
Disabling Access Logging
Disabling Access Logging
You can use the END LOGGING statement to terminate access logging on any user, action, or
object for which one or more logging rules are currently active.
An END LOGGING statement generates an error if a corresponding BEGIN LOGGING
statement is not currently in effect for the object specified in the END LOGGING statement.
Also consider the following END LOGGING characteristics:
•
You cannot omit the BY username clause to apply the END LOGGING to all users.
•
The END LOGGING statement terminates access logging on the database objects included
in the statement. If the END LOGGING statement terminates all logging rules for a
particular user, database, or object, the system deletes the row from DBC.AccLogRuleTbl.
To disable access logging:
1
Query the DBC.AccLogRules view to display the list of BEGIN LOGGING statements
currently in effect:
SELECT * FROM DBC.AccLogRulesV;
2
Submit an END LOGGING statement for each BEGIN LOGGING statement in the list
that you want to end.
Reference Information
For step...
Information on...
Is available in...
use of the END LOGGING
statement
SQL Data Definition Language Syntax and Examples
security logging strategies
Security Administration
Using Access Logs
About Access Logs
Access logging writes information to the logs shown in the following Data Dictionary views.
206
View Name
Description
DBC.AccessLogV
Each entry is the results of a privilege check performed due to a user request
to access a database object. These privilege checks are based on the rules
defined in BEGIN LOGGING statements executed on the system.
DBC.LogOnOffV
Collects a history of logon and logoff activity by date, showing the associated
user, session number, and events such as logon failures. Event data indicates
why a logon was unsuccessful.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 11: Monitoring User Activity
Using Access Logs
Auditing Database Activity Using DBC Log Views
The administrator should perform regular audits of the access logs to detect undesirable
activity, and if necessary take remedial action:
1
To perform a general audit of the security log views:
a
From the main Teradata Administrator screen, click on the bottom left Query button
. Teradata Administrator opens an SQL Assistant query window.
b
From the View menu, ensure that Show History is not checked (the default). This
option shows the history of SQL Assistant queries launched from this client, and is not
necessary for security logging.
c
In the Query window, enter the following SQL to access the security log of interest:
SELECT * FROM [view_name] [table_name]
where:
•
view_name is DBC.AccessLogV or DBC.LogOnOffV
•
table_name is DBC.EventLog
d
Right-click in the Query window and from the menu, click the Execute button
e
As a result of the query, SQL Assistant displays the Answer Set table, which shows the
most recent access log entries, based on the number of rows set for display.
.
Note: You can click Tools>Options>Answer Set to access display format options.
2
You can follow the same procedure shown in step 1, but construct the SQL statement to
narrow the audit parameters. For example:
•
A typical query of the DBC.AccessLog view would be similar to:
SELECT LogDate, UserName, AccessType, StatementText
FROM DBC.AccessLogV
WHERE LogDate ='2009-04-18';
•
A typical query of the DBC.LogOnOff view would be similar to:
SELECT LogDate, LogTime, Event, LogicalHostId, IFPNo
FROM DBC.LogOnOffV
WHERE LogDate='2009-09-29'
AND UserName='Tester'
ORDER BY LogTime;
Reference Information
For step...
Information on...
Is available in...
All
content of the access log tables and
views
• Security Administration
• Data Dictionary
Teradata Data Warehouse Appliance 2690 Implementation Guide
207
Chapter 11: Monitoring User Activity
Checkpoint
Checkpoint
Before leaving Chapter 11: “Monitoring User Activity,” make sure that:
√
Result
Reference
The database is configured to monitor and log
user interactions with the database.
“About Access Logging” on page 197
You understand how to disable access logging.
“Disabling Access Logging” on page 206
You have a program for regular auditing of the
access logs.
“Using Access Logs” on page 206
If you do not have these results, return to the section in the Reference column and review that
procedure.
208
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 12
Monitoring the Database
This section describes how to monitor Teradata Database system health, activity, resources,
and performance, using Teradata Viewpoint.
For information on how to use Teradata Viewpoint monitoring functions to investigate
system problems, see Chapter 13: “Managing the Database.”
Prerequisites
•
A Teradata Viewpoint server is installed and connected to the Teradata Data Warehouse
Appliance 2690 system.
•
The RSS data collection system is enabled on the Teradata Data Warehouse Appliance 2690
system.
•
The Teradata Viewpoint server logon user (viewpoint) exists in the database and has the
privileges necessary to logon and execute database monitoring and management
functions.
•
At least one administrative user is configured to access and administer Teradata Viewpoint
and the Viewpoint data collectors are enabled.
•
All users that you want to setup to access Teradata Viewpoint are defined in the database.
Reference Information
Information on...
Is available in...
Teradata Viewpoint initial setup
requirements described in Prerequisites
Teradata Viewpoint Configuration Guide
Teradata Viewpoint use and administration
Teradata Viewpoint User Guide
Enabling the RSS data collection system
and setting collection rates in the database
using the Control GDO editor (ctl)
Utilities
defining users and granting user privileges
in the database
Chapter 10: “Setting Up Users”
Teradata Data Warehouse Appliance 2690 Implementation Guide
209
Chapter 12: Monitoring the Database
About Viewpoint Monitoring Privileges
About Viewpoint Monitoring Privileges
All database users can benefit from using Teradata Viewpoint to monitor the database, but not
all users need all Teradata Viewpoint capabilities.
You can use the examples in the following table to help determine the database monitoring
functions needed by various user types, and in creating and assigning privileges to Teradata
Viewpoint roles.
Role
Privileges
Default Teradata Viewpoint roles
Administrator
Assign this role only to the Teradata Viewpoint administrator(s).
Has all privileges (default). This role can access the functions in the Admin
tool menu to configure Teradata Viewpoint alerts, users, roles, and systems.
User
Includes minimal privileges
TD_SE (Teradata
Solution Engineer)
This role is intended for the Teradata Solution Engineer when they need
access to system health and metrics. You can enable or disable this role, but do
not reconfigure it.
TD_TSS (Teradata
Technical Support
Specialist)
This role is intended for Teradata Technical Support Specialists when they
need access to your system SQL. You enable or disable this role, but do not
reconfigure it.
Example custom roles
Note: Roles are based on the user types/duties shown in “About User Requirements” on page 171.
Database
Administrator
Database administrators may require all Teradata Viewpoint monitoring
functions to perform administrative duties in the database.
Suggested role privileges: Create a Database Administrator role that has
privileges to use all portlets and portlet functions, except System
Administration, which should only be accessible to the Teradata Viewpoint
administrator(s).
Note: You may find it useful to create an additional role that limits access to
some portlets and functions for lower level administrators.
Database
Programmer/
Power User
Database programmers perform functions similar to administrators, creating
database objects, running ad hoc queries, and monitoring performance.
Suggested role privileges: Similar to Database Administrator, but without
analytical functions.
Note: Programmer privileges in the database are often restricted to a
development database, but Teradata Viewpoint monitors all databases within
the Teradata Data Warehouse Appliance 2690 system.
210
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 12: Monitoring the Database
Setting Up Teradata Viewpoint Users
Role
Privileges
Batch User
Batch users run load and export utilities, or who perform backup, archive and
restore operations.
Suggested role privileges include:
• For job planning:
• Capacity Heat Map
• Space Usage
• Calendar
• During job execution and troubleshooting:
• System Health
• My Queries or Query Monitor
• Workload Monitor
• SQL Scratch Pad
• Console Utilities
• Privilege to set preferences and share portlets
Update User
Users who perform miscellaneous insert/update/delete operations.
Suggested role privileges:
•
•
•
•
•
General User
Calendar (no create or edit privileges)
System Health (View Summary only)
My Queries
Workload Monitor
SQL Scratchpad
Low level users that run macros and stored procedures to access data, which
select data and generate reports.
Suggested role privileges:
• Calendar (no create or edit privileges)
• System Health (View Summary only)
• My Queries
Setting Up Teradata Viewpoint Users
For users that are not already set up to access Teradata Viewpoint, as part of initial system
installation, you must perform Teradata Viewpoint set up operations.
1
Log on as the Teradata Viewpoint administrator and select Admin, which includes a drop
down list of administrative functions.
2
Use the Roles Manager to create Teradata Viewpoint roles and define sets of user privileges
for each role.
When creating roles:
•
Define the protlets available to the role
Teradata Data Warehouse Appliance 2690 Implementation Guide
211
Chapter 12: Monitoring the Database
Working with User Dashboards
•
Define whether user members can set their own preferences and share portlets.
•
Give or remove user permissions for portlet tools and functions.
Teradata Viewpoint provides two default roles, but you may find it useful to configure
custom roles, based on the suggestions in “About Viewpoint Monitoring Privileges” on
page 210.
3
Use the Users Manager to create Teradata Viewpoint users and assign membership in one
or more roles according to user job function. Include an email address for each user, so
that Teradata Viewpoint can send them alert emails, if necessary.
4
Instruct users to setup their Teradata Viewpoint profile by specifying their username,
password, and account, so the system can verify that each user exists in the specified
database system and that the account is valid for the user. Profile information is used by
some portlets, for example:
•
My Queries portlet, to track query activity for the user
•
SQL Scratchpad portlet, to determine database access privileges for the user
Reference Information
Information on...
Is available in...
the duties typically performed by the user types for
which customer roles are recommended
“About User Requirements” on page 171
creating Teradata Viewpoint users, roles, and profiles
• Viewpoint application Help screens
• Teradata Viewpoint User Guide 14.0
Working with User Dashboards
You can create custom dashboard pages, and then use the Add Content function to populate
each page with a set of related portlets from among those available to the user.
The primary dashboard should contain the most important portlets for live monitoring of
database activity, for example:
•
System Health (all)
•
My Queries (users) or Query Monitor (administrators and programmers)
•
1 or 2 other optional portlets, depending on the type of user
You can create additional dashboards to contain other portlets.
Note: You may need to limit the number of portlets per dashboard page. Displaying too many
Teradata Viewpoint portlets on one dashboard may make it hard to find needed data, and for
some browsers, may slow portlet loading and response times.
For details about configuring dashboards and portlets, see Teradata Viewpoint User Guide.
212
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 12: Monitoring the Database
Using Viewpoint Alerts
Creating a Dashboard
From the Teradata Viewpoint portal:
1
Use the Add Page option to name the dashboard, for example, MainDashboard.
2
Use the Add Content function to select portlets to include in the dashboard.
For information on how to use monitoring capabilities to identify and troubleshoot database
problems, see Chapter 13: “Managing the Database.”
Using Viewpoint Alerts
You can configure Teradata Viewpoint to perform alert actions when the database achieves or
exceeds certain defined thresholds.
You can specify the following alert actions individually or in any combination:
•
Write a message to the alert log
•
Send an email message to a specified address
•
Communicate the alert to a specified third-party application
•
Run a specified BTEQ script or other program
Each alert action set has a unique name and is triggered according to the rules for any alert
that specifies the action set name.
The database management tasks shown in Chapter 13: “Managing the Database,” include
other suggested alert protocols.
Setting Up Alert Actions
The alert setup defines alert notification parameters and alert actions.
See Teradata Viewpoint Configuration Guide for procedure details.
1
From the main Teradata Viewpoint portal, select Admin>Setup.
2
Use Delivery Settings/Email to configure communication with the host SMTP email server.
3
Select the Teradata system for which you are configuring the alert.
4
Use Alerts Presets/Action Sets to set up common alert actions, for example, an email
message to all administrative users. Then you can use “Creating Alerts” on page 214 to set
up monitoring parameters that invoke the associated alert action whenever Teradata
Viewpoint detects that a parameter was exceeded.
Note: Specifying one or more roles in the action sends an email to each role member and
is the most efficient way of identifying email recipients. You can list email addresses for any
recipients that are not Teradata Viewpoint users.
Teradata Data Warehouse Appliance 2690 Implementation Guide
213
Chapter 12: Monitoring the Database
Using Viewpoint Alerts
Creating Alerts
A Teradata Viewpoint alert is based on:
•
A threshold specified for a monitoring parameter, for example, when a database exceeds
95% space usage.
•
The time period during which the parameter must be over threshold to invoke the alert.
•
The name of an Action Set, for example, the alert notification created in Setting Up Alert
Actions, which defines who should receive the alert, and how the message is delivered.
•
A message that the system delivers to the list of users defined in the Action Set, if the
threshold and time criteria are met.
To configure a sample alert:
1
From the Teradata Viewpoint main portal, select Admin>Teradata Systems.
2
From the Setup menu, select Alerts, and then configure an alert, for example, a System
Health alert that sends a message if the system is down, similar to the following example.
Note: The Alert Action name “General Alert” is created using Setting Up Alert Actions.
3
Check the Enabled box and click Apply.
Note: See Teradata Viewpoint Configuration Guide for details and options.
214
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 12: Monitoring the Database
Checkpoint
Checkpoint
Before leaving Chapter 12: “Monitoring the Database,” make sure that:
√
Result
Reference
You have determined which Teradata
Viewpoint privileges are appropriate for
user groups at your site.
“About Viewpoint Monitoring Privileges”
on page 210
Database users are configured to access
Teradata Viewpoint.
“Setting Up Teradata Viewpoint Users” on
page 211
Teradata Viewpoint users have dashboard
pages that display related groups of portlets.
“Working with User Dashboards” on
page 212
One or more Teradata Viewpoint alerts are
setup and you understand how to create
additional alerts, as needed.
“Using Viewpoint Alerts” on page 213
Teradata Data Warehouse Appliance 2690 Implementation Guide
215
Chapter 12: Monitoring the Database
Checkpoint
216
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 13
Managing the Database
Database management includes:
•
Space management
•
Query management
•
Workload management
For additional information, see Database Administration.
Prerequisites
•
•
To execute the procedures shown in this chapter, you must have:
•
Teradata Database administrator privileges. See “Setting Up the Database
Administrator User” on page 87.
•
Teradata Viewpoint administrator privileges. See Teradata Viewpoint User Guide.
Teradata Viewpoint is set up for basic monitoring functions. See Chapter 12: “Monitoring
the Database.” This chapter contains additional monitoring recommendations.
About Space Management
Other implementation tasks in this publication include assigning space to databases and users,
but these allocations are based on estimates. Changes in space usage patterns and data
expansion require that you actively monitor database space and make needed changes.
Compressing Data to Save Space
Teradata recommends that you use one or more of these compression options to conserve disk
space:
•
Multi-value compression
•
Algorithmic compression
•
Hash/Join index row compression
•
Block-level compression
You can use these compression methods in any combination for space savings of as much as
80% to 90%, depending on the characteristics of the data being compressed.
Teradata Data Warehouse Appliance 2690 Implementation Guide
217
Chapter 13: Managing the Database
Compressing Data to Save Space
Using Multi-Value Compression (MVC)
MVC compresses repeating values in a column when you specify the value in a compression
list in the column definition.
When data in the column matches a value specified in the compression list, the database stores
the value only once in the table header, regardless of how many times it occurs as a field value
for the column. The database then stores a smaller substitute value, often as small as 2 bits, in
each row where the value occurs.
MVC generally provides the best cost/benefit ratio compared to other methods. Because it
requires minimal resources to uncompress the data during query processing, you can use
MVC for hot (frequently-used) data without compromising query/load performance.
Procedure
1
Use the COMPRESS phrase in a CREATE TABLE or ALTER TABLE statement to specify a
list of frequently occurring values for the column that contains the values.
2
The system automatically compresses the specified values when data moves into the table,
and uncompresses them when the containing rows are accessed.
Using Algorithmic Compression (ALC)
Teradata Database provides several standard compression algorithms in the form of user
defined functions (UDFs), and also an algorithmic compression framework that allows you to
create custom compression and decompression algorithms in UDF format.
The standard algorithmic compression (ALC) UDFs compress character data by column.
When column values are mostly unique, ALC may provide better compression results than
MVC. When columns have repeated values, you can use ALC and MVC concurrently on the
same column, but the system does not apply ALC to any value covered by MVC.
ALC generally functions best on cold (seldom used) data, because of the amount of CPU
required for the decompress/recompress cycle when compressed data is accessed, although
some ALC algorithms require less CPU than others.
Procedure
1
Specify the name of an ALC compression UDF in the COMPRESS USING phrase for a
column definition in a CREATE TABLE or ALTER TABLE statement.
2
Specify the name of an ALC decompression UDF in the DECOMPRESS USING phrase for
the column definition.
Using Hash Index and Join Index Row Compression
Row compression automatically divides rows into repeating and nonrepeating portions. The
system appends multiple sets of nonrepeating column values to a single set of repeating
column values. This allows the system to store the repeating value set only once, while any
nonrepeating column values are stored as logical segmental extensions of the base repeating
set. The nonrepeating column set has a pointer to each of the repeating column sets so it can
reconstruct the rows when required.
218
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Compressing Data to Save Space
Row compression significantly reduces index storage space for index columns that have a large
number of repeating values.
For hash indexes, the system compresses rows by default.
For join indexes you can:
1
Specify the columns to be compressed using the (column_1_name) syntax elements in the
SELECT clause of a CREATE JOIN INDEX statement.
2
Specify the columns to remain uncompressed using the (column_2_name) syntax elements
in the SELECT clause for the same CREATE JOIN INDEX statement.
About Block Level Compression
Teradata Database stores table data in units called data blocks (DBs); physical units of I/O that
determine how the Teradata Database file system handles data. The DATABLOCKSIZE option
in a CREATE TABLE or ALTER TABLE statement defines the maximum multi-row data block
size for a table.
You can enable block level compression (BLC) to cause the database to store DBs for specified
tables or table types in compressed format.
The uncompress/recompress cycle that occurs when users access BLC data is CPU intensive, so
the Teradata Database Appliance 2690 system is equipped with compression hardware, which
handles BLC compression processing without impacting node CPU usage.
Enabling Block Level Compression
1
Use the DBS Control utility to control BLC.
•
Enable BLC using the BlockLevelCompression field.
•
Specify use of the compression hardware by setting the CompressionAlgorithm field to
ELZS-H.
Note: If the BLC hardware fails you can change the setting to ELZS-S to use the
matching software compression algorithm until the hardware is operational.
•
Specify the table types for which BLC is enabled using other DBSControl compression
fields. The system automatically compresses data loaded into any empty table that is
specified for use of BLC by table type.
Note: You can use the BlockCompression query band to override the default
compression for a table that results from a table type setting in DBS Control.
•
Specify BLC thresholds using the needed DBSControl fields.
For information on BLC settings, see the DBS Control utility chapter in Utilities: Volume 1
(A-K)
2
Set the DATABLOCKSIZE to the maximum 255 sectors (130,560 bytes), using the
CREATE TABLE or ALTER TABLE statement, for tables that use BLC.
3
After enabling BLC and setting compression thresholds, you can use the Ferret utility
COMPRESS or UNCOMPRESS commands to apply or remove BLC for a populated table.
Teradata Data Warehouse Appliance 2690 Implementation Guide
219
Chapter 13: Managing the Database
Compressing Data to Save Space
Note: You can use the Ferret SHOWCOMPRESS command to list the tables that are
currently using BLC. See “Ferret” in Utilities: Volume 1 (A-K).
Updating Space Accounting for BLC
When you apply BLC to a populated table you must run the Update Space utility to update
system space accounting reports for the containing database.
1
Log on to cnsterm. See “Running Database Utilities From Viewpoint” on page 237.
2
Open the Update Space utility and run the Update Space command for a specific database
or all databases:
UPDATE SPACE FOR {ALL DATABASES | databasename};
For details on UPDATE SPACE, see Utilities: Volume 2 (L-Z).
Reference Information
Information on...
Is available in...
specifying MVC or ALC compression in a
CREATE TABLE or ALTER TABLE statement
SQL Data Definition Language Syntax and
Examples
specifying join index row compression in a
CREATE JOIN INDEX statement
220
using the Ferret utility COMPRESS and
UNCOMPRESS commands to apply BLC to
populated tables
Utilities Volume 1
using the DBS Control utility to set or modify
BLC parameters
Utilities Volume 1
using the BlockCompression query band in a
SET QUERY BAND statement to override BLC
settings
SQL Data Definition Language - Detailed Topics
compression usage and restrictions,
determining the maximum number of
compressed values, calculating space and I/O
savings, and comparisons between using MVC
and ALC
• Database Design
• Database Administration
applying compression to various data types
using the COMPRESS and DECOMPRESS
phrases
SQL Data Types and Literals
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Identifying and Correcting Space Problems
You can use Teradata Viewpoint to monitor database space usage and detect space problems.
Space problems vary depending on the type of space and how the system uses it.
Space Type
Usage
Permanent (Perm)
Permanent storage space contains objects that persist in the database, for
example, tables, indexes, and journals. Perm space is assigned in a:
• CREATE DATABASE or MODIFY DATABASE statement
• CREATE USER or MODIFY USER statement
When you create an object, or when data rows are inserted into an object,
the system takes the needed space from the perm space of the immediate
owner of the object. The system automatically returns the space to the
owner when it is no longer needed.
Spool
Spool space holds intermediate query results, the formatted answer sets to
queries, and volatile tables (if used). The system automatically draws spool
space from unused system disk space.
You can specify a limit on the amount of spool space available to a user or
database in a:
• CREATE DATABASE or MODIFY DATABASE statement
• CREATE PROFILE or MODIFY PROFILE statement
• CREATE USER or MODIFY USER statement
If you do not specify a spool space limit, a user automatically inherits the
spool limit of the immediate owner.
Temporary (Temp)
Temp space stores global temporary tables.
Global temporary tables are an advanced feature, and not covered in this
publication. For information on temporary tables, see Database
Administration.
Identifying Space Problems
Several Teradata Viewpoint portlets provide space usage information, which you can use to
identify space problems.
System Health Portlet
Use the System Health portlet to track current system-level space usage. This portlet displays
segmented bar graphs that show normal, degraded and critical space usage ranges.
Parameter
Description
Actions
Total disk space
Percentage of total disk space
in use across the system
If system disk space usage moves beyond
the normal range (80%), add disk capacity.
Teradata Data Warehouse Appliance 2690 Implementation Guide
221
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Parameter
Description
Actions
DBC disk space
Percent of disk space assigned
to DBC currently in use
The DBC database contains logs, system
tables and views, and other functions
necessary for system operation.
If DBC space usage moves beyond the
normal range, reallocate perm space from
DBADMIN to DBC.
Space Usage Portlet
Use the Space Usage portlet to track detailed space usage parameters, including available
space, current usage, and peak usage for each space type, by database or user.
1
Select the system you want to investigate and click Next>.
2
In the selection menu, select Database: By most space and click Next>.
3
Use the Database Total view to display perm space usage for all databases that have
assigned perm space. The following columns may indicate perm space problems.
Parameter
Description
Actions
Current
Perm%
Percentage of available perm
space currently being used by
each user and database.
Peak Perm%
The highest percentage of total
available perm used by each
user and database since the last
reset (default 24 hours).
Consider allocating additional perm space to
any user or database when it reaches 90% perm
space usage. See “Reallocating Perm Space” on
page 223.
Current Perm
Skew%
A measure of how the perm
space for a database distributes
across all AMPs. Higher
percentages indicate uneven
distribution.
A high perm skew percentage indicates that one
or more tables in the database is skewed, that is,
it has a poorly designed primary index.
To identify skewed tables, see “Finding and
Fixing Skewed Tables” on page 224.
Note: If you think there is a space problem, you can click on a database name to display
the Details view, which shows the current perm, peak perm, and skew% for each table in
the database.
4
Use the Users Over 85% Spool view to display any users that have exceeded the safe range
of spool usage since the last reset.
Note: In some cases excess spool usage may be the result of poorly constructed queries
rather than an actual shortage of spool. See “Identifying Bad Queries” on page 227.
222
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Parameter
Description
Actions
Current Spool%
Percentage of available spool
space currently being used by
each user and database (list)
Monitor regularly to determine whether
certain users regularly exceed 85% spool.
Peak Spool%
Largest percentage of available
spool space recently used by
each listed user and database
since the last reset (default 24
hours).
• Use Query Monitor to track query
activity for users exceeding the limit, to
determine whether the excessive spool
usage is caused by poorly constructed
queries. See “Managing Query
Problems” on page 226.
• Increase the spool space limit for users
who need spool by modifying the user
or applicable profile definition. See
“Increasing the Spool Space Limit for a
User” on page 223.
Using the Capacity Heatmap
The Capacity Heatmap portlet displays many of the same parameters as the Space Usage
portlet, but allows you to see space usage trends over several months. A review of space usage
trends in Capacity Heatmap can be useful when planning and scheduling batch jobs or other
large space-using tasks, or when estimating growth in system disk requirements.
Reallocating Perm Space
1
In the Space Usage portlet, highlight the database or user that requires more space.
Note: You can also define the value for spool in a profile, and then assign profile
membership to a user. See “Working with Profiles” on page 175.
2
Click the Add Space button and:
•
Enter the username and password of a database user that has DROP privileges
(required for use of the MODIFY statement) on the database or user that requires
more perm space.
•
Enter the space in MBs and the name of the user or database that directly owns the
perm space being transferred.
The system generates a MODIFY DATABASE or MODIFY USER statement that reallocates
the space.
Increasing the Spool Space Limit for a User
Specify a new value for SPOOL in a MODIFY PROFILE or MODIFY USER statement,
depending on where the user spool is defined, for example:
MODIFY [PROFILE profile_name | USER user_name ] AS
SPOOL = bytes ;
Teradata Data Warehouse Appliance 2690 Implementation Guide
223
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Finding and Fixing Skewed Tables
The DBC.TableSizeV contains information that can help identify skewed tables. Table skew
results from an inappropriate primary index. A query that references a skewed table may try to
process more rows on some AMPs than others, and may run out of space:
•
SELECT statements may run out of spool space if the accessed object has a defined spool
space limit.
•
INSERT and UPDATE statements may run out of perm space.
1
Use the following SQL statement to find skewed tables in the DBC.TableSizeV:
SELECT vproc AS
"AMP", TableName (FORMAT 'X(20)'), CurrentPerm
FROM DBC.TableSizeV
WHERE DatabaseName = 'database'
ORDER BY TableName, "AMP" ;
AMP
--0
1
2
3
0
1
2
3
TableName
--------------------employee_upi_onempid
employee_upi_onempid
employee_upi_onempid
employee_upi_onempid
employee_nupi_ondept
employee_nupi_ondept
employee_nupi_ondept
employee_nupi_ondept
CurrentPerm
-----------18,944
18,944
18,944
19,968
4,096
30,208
15,360
12,288
In this example, the answer set displays space allocations by AMP for two tables. The
results show that:
2
•
CurrentPerm is similar across all vprocs for employee_upi_onempid. Permanent space
distribution is relatively even across all AMPs in the system.
•
The table Employee_nupi_ondept is poorly distributed. The CurrentPerm figures
range from 4,096 bytes to 30,208 bytes on different AMPs.
Redefine the primary index for any skewed tables that you find. See “About Primary
Indexes” on page 109.
Setting Up Teradata Viewpoint Alerts for Space Usage
You can use Teradata Viewpoint to regularly monitor space usage, and catch most space
problems. However, it may be useful to setup a few alerts in areas where space problems can
seriously affect database function. See “Using Viewpoint Alerts” on page 213.
The following table contains some examples of common space usage alerts.
224
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Alert
Setup Parameters
Response to Alert Occurrence
Crashdumps Space
Alert rules:
The crashdumps database
needs enough space to
contain possible large data
dumps that occur during
crashes, and which are
used in system recovery.
• Only include databases =
crashdumps
• Current Perm Max% > 70
Note: The threshold is set low
because a crashdump can be
very large.
• Add perm space to the
crashdumps database. See
“Assigning Perm Space to
Crashdumps” on page 85.
• Purge the crashdumps
database of unneeded data
and back up needed data to
external media.
See Database Administration.
Alert Action:
• Email
• Do not run twice in 5 minutes
Severity: Medium
DBC Space
Alert rules:
Add perm space to the database.
User DBC contains all
system tables and logs.
Critical system functions
depend on DBC having
enough space.
• Only include databases = DBC
• Current Perm Max% > 80
Note: Use 90% for SystemFE.
See “Assigning Perm Space to
Crashdumps” on page 85 for
information on the DBC space
allocation for appliance
implementation.
Alert Action:
Note: You can set the same
alert parameters for
DBCMNGR and
SystemFE, which perform
other critical system
functions.
• Email
• Do not run twice in 5 minutes
Severity: Medium
Set up three alerts to
identify when a database
exceeds important space
thresholds.
Alert rules:
• All DB 90%
• All DB 95%
• All DB 97%
• All databases
• Current Perm Max%
> percent
Alert Action:
• Email (Pager for critical alerts)
• Do not run twice in 5 minutes
Severity: (apply one of the
following to the related alert)
• Medium (90%)
• High (95%)
• Critical (97%)
Teradata Data Warehouse Appliance 2690 Implementation Guide
You should allocate additional
perm space to a database as soon
as possible after perm space
usage exceeds 90%.
Databases that trigger the High
or Critical alert levels before you
can respond to a Medium alert
are growing very fast and should
receive more space immediately.
You can investigate which tables
are using database perm space.
See “Identifying Space
Problems” on page 221.
225
Chapter 13: Managing the Database
Managing Query Problems
Managing Query Problems
About Common Query Problems
Query Problem
Result
Stale statistics
The optimizer uses statistics to plan query execution. If the statistics
are out of date, the optimizer may create a poor plan.
Recommendation: Review tables to see whether statistics are out of
date, and recollect statistics if required, as shown in “Recollecting
Statistics when Existing Statistics Are Stale” on page 161.
Badly skewed data
Causes table rows to be distributed unevenly among AMPs and
queries to execute unevenly, which slows processing time.
Recommendation: Monitor table skew. Redefine the primary index
if required. See “Finding and Fixing Skewed Tables” on page 224.
Poor query construction
Poor SQL syntax or missed punctuation can result in bad queries.
Recommendations:
• Identify bad queries and the users responsible for them. See
“Identifying Bad Queries” on page 227
• Abort bad queries when required. See “Controlling Bad Queries”
on page 227.
Concurrency issues
Some queries are delayed or prevented from executing because of
lock contentions, or the relative priorities of concurrent queries.
Recommendations:
• Identify the cause of a delayed query. See “Investigating Query
Blocks and Delays” on page 229.
• Release a query from the delay cue. See “Controlling Bad
Queries” on page 227.
• Change the priority for a database operation or user. See
“Changing the Priority Level for a Session or Request” on
page 232.
• Establish more detailed concurrency controls using Teradata
Workload Management. See “Managing the Database with
Teradata Workload Management” on page 234.
Setting Up Lock Logging Parameters
Use the DBSControl utility to set the LockLogger field to TRUE, which enables the logging of
lock-related data, and the identification of specific lock contentions.
Note: The Teradata Viewpoint Lock Viewer portlet uses LockLogger data to generate a
continuous report of database lock activity, based on the settings for the:
226
•
Time interval defined in the Lock Info data collector (default 3600 seconds)
•
Log table columns checked as enabled in Change display configuration arrow
Lock Viewer portlet.
for the
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Managing Query Problems
Identifying Bad Queries
When notified of delays by a user or an alert, you can use the Teradata Viewpoint Query
Monitor portlet to find out if the delay is the result of a bad query.
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 user and account
that submitted the query.
4
Select the SQL tab to display the SQL for 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 active steps,
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.
If a bad query causes problems in the database, you can:
•
Use Query Monitor to control the query. See Controlling Bad Queries.
•
Use the SET SESSION ACCOUNT request to re-assign a poorly-performing query to a
lower-priority account. See “Changing the Priority Level for a Session or Request” on
page 232.
Controlling Bad Queries
To control a query:
1
In the Query Monitor portlet, click on the session with the identified bad query. The
Details view appears.
2
You can use the Tools menu to:
•
Change the query priority
Teradata Data Warehouse Appliance 2690 Implementation Guide
227
Chapter 13: Managing the Database
Managing Query Problems
•
Abort the query
•
Abort and log off the session
Note: Use the following guidelines when considering whether to abort a session:
•
Do not abort the session if it is still running other queries.
•
If the session is not running other queries:
•
If the query is a SELECT statement, you can safely abort the query.
•
If the query includes an INSERT, UPDATE, DELETE, or other statement that
changes data, aborting a partially completed query may cause data problems.
About Lock Contentions
Teradata Database uses the Lock Manager to automatically lock database objects accessed by
each transaction, to prevent or limit simultaneous access by other transactions. Before the
transaction begins, the Lock Manager requests a lock on the data. When the transaction is
complete, the Lock Manager releases the lock.
Locks have different degrees of severity or exclusivity according to the type of transaction
being processed.
Lock Level
Description
Read
Prevents write and exclusive locks. Generally caused by a SELECT.
Ensures consistency during read operations. Several users may hold concurrent read
locks on the same data, during which no modification of the data is permitted.
Write
Prevents other read, write, and exclusive locks. Generally caused by an INSERT,
UPDATE, or DELETE statement.
Enables users to modify data while locking out all other users except those using access
locks. Until a write lock releases, no new read or write locks are allowed.
Exclusive
Prevents any other type of concurrent access. Generally caused by statements that
make structural changes, for example, using an ALTER TABLE statement to add, drop,
or change a column, when the statement uses the LOCKING modifier.
Exclusive locks are the most restrictive type of lock. When you hold an exclusive lock,
other users cannot read or write to the data.
Access
Prevents exclusive locks only. Caused by the LOCKING…FOR ACCESS statement
modifier.
This type of lock allows for reading data while modifications are in process. Access
locks are designed for decision support on large tables that are updated only by small,
single-row changes. Access locks can cause “stale reads,” in that other concurrent
queries may access data that has not been updated.
228
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Managing Query Problems
Investigating Query Blocks and Delays
Most blocks are momentary and do not require attention. However, if a block persists, you can
investigate it to identify the cause and determine whether further action is required.
1
Use the Teradata Viewpoint Query Monitor portlet to monitor the parameters related to
query blocks and delays.
State
Description
Blocked
Indicates that a session query is held up by a lock on an object that the query is
attempting to access.
Blocked Time
How long the query has been blocked.
Momentary locks are normal and not harmful. Persistent locks may indicate:
• A runaway query or hung query that cannot complete and release its locks,
and which should be aborted
• A long-running query, such as large-scale update or backup operation,
which should be rescheduled to avoid resource contention
Delayed
2
3
Indicates that the query is in a delay queue caused by a workload rule.
Click the session ID for the query to access the Details View.
•
If a query is blocked, see the Blocked By tab for details
•
If the query is delayed, the Delay tab provides details about the cause of the delay
You can also use the Lock Viewer portlet to find out additional details about the block:
•
Block Time
•
Database
•
Table
•
Delay
•
Blocked User
•
Blocking Level
•
Blocking User
Reference Information
Information on...
Is available in...
Locking Logger, Lock Display, and Show Locks
utilities
Utilities: Volume 2 (L-Z)
managing locks
Database Administration
lock and transaction processing
SQL Request and Transaction Processing
Teradata Data Warehouse Appliance 2690 Implementation Guide
229
Chapter 13: Managing the Database
Using Performance Groups to Manage Job Priorities
Using Performance Groups to Manage Job
Priorities
The Teradata Data Warehouse Appliance 2690 has four predefined performance groups that
you can assign to users in user accounts. All users should have at least one account and each
account should specify a performance group. See “Working with User Accounts” on page 173.
Users that do not have an assigned performance group automatically default to $M (medium)
priority. For details on relative priorities among performance groups, see System Enforced Job
Priorities.
The Teradata Viewpoint Workload Designer portlet provides additional tools for controlling
workloads. See “Managing the Database with Teradata Workload Management” on page 234.
How the System Determines the Session Account
When a user logs on, the system determines the session account based on the following
hierarchy. Each account source supersedes the source that precedes it in the hierarchy.
•
The default user account (first account specified) in the:
•
User definition
•
User profile, if the user is a profile member
•
A user account specified in the logon string, when the user has multiple accounts and does
not want to use the default.
•
An account specified in a SET SESSION ACCOUNT statement, as described in “Changing
the Priority Level for a Session or Request” on page 232. The statement is often used when
the user has multiple accounts, and needs to change accounts among several jobs/requests
run in the same session.
Note: If an account string is not available from these sources, the system uses the default
account for the parent user. This is not recommended because the parent user priority level
may be inappropriate.
System Enforced Job Priorities
The system enforces session priorities according to the relative priority weights of the active
performance groups for simultaneously executing queries.
230
Performance Group
Priority Level
Relative Priority Weight
$R
Rush
8x (~53%)
$H
High
4x (~26%)
$M
Medium
2x (~14%)
$L
Low
1x (~7%)
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Using Performance Groups to Manage Job Priorities
The relative weight determines the processing resource allocation among active performance
groups and the frequency with which the system offers CPU to jobs running at that priority
level. Relative weight does not predict actual CPU usage or consumption. Lower-priority jobs
receive more CPU when higher-priority jobs are not using it.
A set typical performance group assignment might be similar to the following list:
•
$R: Emergency jobs
•
$H: Short (sub-second) queries
•
$M: Longer queries
•
$L: Large batch jobs and reports.
Note: These assignments are shown only as examples. Always assign performance groups
according to site-specific business needs.
CPU Milestones for Performance Groups
Each performance group has a predetermined CPU usage milestone (a time limit), after which
the system demotes long-running jobs to a lower priority. For example, a job that starts with a
rush priority degrades to a medium priority when it exceeds the CPU milestone for $R. The
job priority can degrade all the way to low if it exceeds all milestones.
You can bypass CPU to avoid degradation in priority level if such degradation does not meet
your business needs. See “Disabling and Re-enabling CPU Milestones” on page 233.
The CPU milestones in the following table are fixed, when enabled.
Performance Group
CPU Usage Milestone
Database Action When Milestone Is Exceeded
$R
10 seconds
The service priority changes to Medium.
$H
10 seconds
The service priority changes to Medium.
$M
200 seconds
The service priority changes to Low.
$L
None
None
Checking Priority Scheduler Settings and Usage with schmon
You can use the schmon utility to:
•
Display current priority settings
•
Display and monitor resource usage statistics for nodes and priority levels
•
Display priority data for the specified sessions from the current node or all nodes
You cannot use schmon to change a priority.
1
Open the Remote Console portlet.
2
Select the Priority Scheduler utility from the menu. The following schmon options are
available on the Teradata Data Warehouse Appliance 2690.
Teradata Data Warehouse Appliance 2690 Implementation Guide
231
Chapter 13: Managing the Database
Using Performance Groups to Manage Job Priorities
Schmon Option
Description
-d
Displays the current priority settings in multi-line format.
-h
Displays help for schmon. You can specify one or more schmon top-level
options (for example, -M) on which to display extended help information.
-m
The schmon -m option displays or monitors priority resource usage statistics.
-M
Displays or monitors priority resource usage statistics for all nodes of an MPP.
-s
Displays priority data for the specified sessions from the current node or all
nodes in the Teradata Database system.
For schmon syntax, usage notes, and examples, see Utilities: Volume 2 (L-Z).
Finding All Accounts with a Rush Priority
Queries with a Rush priority may delay other concurrent queries if there is resource
contention.
You can use the following request to select all account strings with a particular priority code
(for example RUSH) to determine if the assigned users actually require the priority:
SELECT AccountName,UserName,UserOrProfile
FROM DBC.AccountInfoV
WHERE AccountName LIKE '$R%'
ORDER BY AccountName ;
The example query returns information on the users assigned to RUSH accounts and whether
the accounts are assigned in the user or profile definition.
AccountName
-------------$R$_ABCD&S&D&H
$R$_EFGH&S&D&H
$R$_IJKL&S&D&H
$R$_MNOP&S&D&H
$R$_QRST&S&D&H
UserName
--------------AcctsRecv
DBADMIN
DBC
SysAdmin
SystemFe
UserOrProfile
------------Profile
User
User
User
User
Changing the Priority Level for a Session or Request
You can change the priority level for a request using the SET SESSION ACCOUNT statement,
for example:
SET SESSION ACCOUNT='$H0+FIN1&S&D&H' FOR REQUEST;
In this example a user switches the account for use during a subsequent SQL request from the
default to another assigned account with a higher priority, $H0+FIN1&S&D&H:
SET SESSION ACCOUNT must specify an account that is assigned to the user executing the
request, either in the user definition or in a profile of which the user is a member.
232
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Using Performance Groups to Manage Job Priorities
Recommendation: If CPU milestones are active, disable them before changing the priority
level for a session or request. Otherwise, the new priority is subject to automatic demotion
based on CPU milestones.
Disabling and Re-enabling CPU Milestones
If CPU milestones are active, they can change the assigned priority level for a session or
request when the milestone is exceeded. This can result in a demotion to lower priority. If you
want all requests to always run at their assigned priority, you can disable the CPU milestones.
Note: You cannot disable milestones selectively. Milestones are either on or off for all requests.
Use the following procedure to disable and re-enable the CPU milestones.
Note: Running schmon (a console utility) requires special privileges. See “CNS Permission
Requirements” on page 238.
1
Issue the following at the Teradata command line. For more information on the command
line, see “Running Database Utilities From Viewpoint” on page 237.
schmon -G DEFAULTSETTINGS
2
Restart Teradata Database to apply the new settings. See “Initiating a Manual Restart” on
page 248.
To reapply CPU milestones for performance levels, follow this procedure:
1
Issue the following at the Teradata command line:
schmon -G CLEAR
2
Restart Teradata Database to apply the new settings. See “Initiating a Manual Restart” on
page 248.
Note: Neither of the schmon -G procedures shown in this section takes effect if Teradata
Viewpoint filters and throttles are active. Disable filters and throttles before issuing the
command. For more information on filters and throttles, see “Managing the Database with
Teradata Workload Management” on page 234.
Reference Information
Information on...
Is available in...
adding or modifying priorities in a profile
“Working with Profiles” on page 175.
changing the priority level for a session or
request
SQL Data Definition Language Syntax and
Examples
monitoring priority levels using schmon
Utilities: Volume 2 (L-Z)
Teradata Data Warehouse Appliance 2690 Implementation Guide
233
Chapter 13: Managing the Database
Managing the Database with Teradata Workload Management
Managing the Database with Teradata
Workload Management
To implement Teradata Workload Management on Teradata Data Warehouse Appliance 2690:
1
Determine workload management needs.
2
Create a ruleset and define the general parameters.
3
Define session rules.
4
Define filter rules.
5
Define throttle rules.
Determining Workload Management Needs
Before defining Teradata Workload Management parameters, evaluate how your database is
used. The objective is to identify job handling and query limitation needs that cannot be met
by performance group assignments and scheduling.
•
Determine database activity trends using the Teradata Viewpoint Capacity Heatmap
portlet to understand overall workload concurrency and possible resource contention. For
information on the Capacity Heatmap portlet, see Teradata Viewpoint User Guide.
•
Use the Teradata Viewpoint Query Monitor and Lock Viewer portlets to study resource
contention at various times of day and to understand blocking and wait time patterns. See
the sections beginning with “About Lock Contentions” on page 228.
•
Optionally use the database query logging (DBQL) logging feature to determine query
performance details. For information on tracking processing behavior with DBQL, see
Database Administration.
•
Optionally monitor the ResUsageSPS table to determine resource usage by performance
group. For information on the ResUsageSPS table, see Data Dictionary.
Defining a Teradata Workload Management Ruleset
You must create a ruleset to contain your workload management rules. You can create
multiple rulesets, but only one ruleset can be active at a time. For instructions on using the
Workload Designer portlet, see Teradata Viewpoint User Guide.
In the Ruleset General View:
1
Name the ruleset.
2
Use the default Interval settings.
3
Use the default Blocker settings.
4
In the Activation tab, select the features that will be enabled when the ruleset is activated:
Filters and Utility Sessions, System Throttles and Session Control, or both.
5
Defining Bypass rules is optional, but not recommended for initial implementation.
Note: User DBC bypasses all rules by default.
234
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 13: Managing the Database
Managing the Database with Teradata Workload Management
6
Create the needed classification criteria for session control, filters, and throttles within the
ruleset to manage your database workload, as shown in the following topics.
Classification Settings
You can set classification criteria for your filter or throttle rules to narrow the effects of the
rules, unless you want a rule to apply globally. For example:
•
Request source: Username, account name, account string, profile, application, client IP
address, client ID, performance group.
•
Target: The name of a database object that the query accesses, for example, a database,
table, view, macro, or stored procedure.
•
Query characteristics: Statement type, AMP limits, step row count, final row count, or
estimated processing time.
•
Query ban.d
•
Utility (source of query) (available for filters only).
Note: Classifications are fixed across all states for the Teradata Data Warehouse Appliance
2690.
Session Rules
You can use the Sessions tab in a ruleset to limit the:
•
Number of concurrent sessions logged on at one time (Query Sessions). You can add
request source classification criteria to this limit. See “Classification Settings”.
•
Number of concurrent utility sessions.
•
Number of concurrent sessions for a specific utility.
•
Order of precedence of utility session rules.
Note: State-based session parameters are not available on a Teradata Data Warehouse
Appliance 2690.
Filters
Filters reject a query of a certain type before the query starts running. You can use filters to
prevent out of control queries or to restrict some types of work to certain hours, for example.
You can apply filters globally or according to classification rules. See “Classification Settings”.
For example, you can create a filter that prohibits a specific user (request source classification)
from running a query with an estimated processing time of longer than 15 minutes (query
characteristics classification).
For information on ruleset filters, see Teradata Viewpoint User Guide.
Throttles
Throttles limit the number of queries that run concurrently. You choose what happens when a
throttle limit is reached. Any new queries that exceed the limit can be rejected or go into a
delay queue.
Teradata Data Warehouse Appliance 2690 Implementation Guide
235
Chapter 13: Managing the Database
Checkpoint
For example, you can create throttles to limit:
•
A specific user (request source classification) to running no more than 10 queries at a time
(query session limit)
•
The number of utilities (utility classification) simultaneously executing against a table
(target classification)
Suggested Custom Throttles
The following example throttles can be useful for most implementations.
Throttle all at 52:
•
Limits the database to the execution of 52 concurrent queries.
•
Places additional queries into the delay queue.
•
Prevents unusually large query demand from putting the system into flow control.
Throttle High, Medium, and Low PG queries with an estimated processing time > 1 second:
•
Sets a limit of 30 concurrently executing H, M, or L queries that have an estimated
processing time of > 1 second. There is no built-in limit on shorter queries.
•
Places additional long queries into the delay queue.
•
This throttle does not apply to short queries (<1 sec), or to an R query of any size.
Checkpoint
Before leaving Chapter 13: “Managing the Database,” make sure that:
√
Result
Reference
You have evaluated compression options and
implemented those that apply to your system.
“Compressing Data to Save Space” on
page 217
You can monitor and manage database space.
“Identifying and Correcting Space
Problems” on page 221
You can monitor and manage database queries.
“Managing Query Problems” on
page 226
You understand how to use performance groups
to manage session priorities.
“Using Performance Groups to Manage
Job Priorities” on page 230
You understand Teradata Workload
Management capabilities and have implemented
needed workload controls.
“Managing the Database with Teradata
Workload Management” on page 234
If you do not have a result, review and redo the procedure shown in the Reference column.
236
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 14
Maintaining the Database
This section discusses database management utilities and tasks that must be performed to
maintain system health and optimal function.
Teradata Database Console Utilities
Teradata Data Warehouse Appliance 2690 administration tasks require that you run Teradata
Database console utilities. The following topics describe several ways to access the utilities:
•
Running Database Utilities From Viewpoint
•
Running Database Utilities from cnsterm
•
Running Database Utilities from a Database Node
Note: Database utilities can have negative effects on the database if they are not run correctly,
and should be used only by trained personnel, as specified in documented procedures or
under the direction of Teradata Customer Support.
Running Database Utilities From Viewpoint
You can run some database-level utilities from the Teradata Viewpoint Remote Console
portlet. For setup and usage information, see “Remote Console” in Teradata Viewpoint User
Guide.
•
Abort Host
•
CheckTable
•
Configuration Utility
•
DBS Control
•
Ferret Utility
•
Gateway Global
•
Lock Display
•
Operator Console
•
Priority Scheduler
•
Query Configuration
•
Query Session
•
Recovery Manager
•
Show Locks
•
Teradata DWM Dump
•
Vproc Manager
Teradata Data Warehouse Appliance 2690 Implementation Guide
237
Chapter 14: Maintaining the Database
Teradata Database Console Utilities
Reference Information
Information on...
Is available in...
utility functions, syntax, options,
• Utilities Volume 1 (A-K)
• Utilities Volume 2 (L-Z)
Running Database Utilities from cnsterm
You can run all database utilities from the Teradata Database Console Subsystem (CNS). Some
utilities, such as DIP, can only run from this interface.
The cnsterm program is a user interface to the Console Subsystem (CNS). CNS provides six
virtual interface windows:
•
Windows 1 through 4 are interactive application windows in which database utilities run.
•
Window 5 is the database I/O window, which displays messages from database programs,
such as SQL diagnostics, that do not run in CNS application windows.
•
Window 6 is the Supervisor window, the primary user interface to CNS. Launch database
utilities in the Supervisor window, and they run in the application windows.
You can use the Supervisor window to issue CNS commands to the database. For more
information on CNS commands
Note: You can issue CNS commands to the database from the Supervisor window, and
also run console utilities from Database Window (DBW), an X-window based graphical
user interface. See “Database Window” in Utilities: Volume 1 (A-K).
CNS Permission Requirements
The root user on the control node is automatically authorized to access CNS, and can run all
database-level utilities from cnsterm or DBW. However, Teradata recommends that access to
root privileges be severely limited, even among administrative users.
To run console utilities without root privileges, an administrative user must be either:
•
A member of the Linux tdtrusted group, which is automatically created during the initial
installation and configuration of the Teradata Data Warehouse Appliance 2690 system,
and which has permission to run console utilities.
•
Explicitly granted the right to run console utilities with the CNS GRANT command.
Granting CNS Permissions
Do the following to grant users who do not have root privileges or membership in the
tdtrusted group permission to access CNS and run database utilities.
1
Access the CNS Supervisor window by entering cnsterm at the control node command
prompt.
2
To grant another user account permission to access CNS via cnsterm or DBW to run all
database-level utilities, enter:
grant user_ID@localhost all
238
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Teradata Database Console Utilities
where user_ID is the account the user uses to log on to control node.
Note: The permissions should be granted or revoked only when all TPA nodes are
running.
For example:
Input Supervisor Command:
> grant vsattui@localhost all
grant vsattui@localhost all
CNSSUPV: permissions for vsattui@localhost updated
vsattui@localhost: all
3
Exit cnsterm by pressing Ctrl-C. The new permissions take effect immediately.
Reference Information
Information on...
Is available in...
CNS permissions and the CNS GRANT
command
“Database Window” in Utilities: Volume 1 (A-K)
Logging on to the Control Node
The cnsterm program runs only from the control node, which is typically the lowest
numbered running system node. This procedure describes accessing the control node from
SMClient.
1
From a workstation that has been set up using the procedures described in “Configuring a
Workstation for Use with SMWeb” on page 37, navigate to the SMWeb Home page by
following the procedure described in “Accessing the SMWeb Home Page” on page 38.
2
Select Server Management Client.
3
Log in as a Service User.
4
In the SMClient Tree View, right-click the control node, and click Connect.
Note: The control node is the lowest numbered running node in the lowest numbered
cabinet in the Teradata Data Warehouse Appliance 2690 system. The control node is
typically shown as Node 2 in the Tree View. Do not select a server management node
(CMIC, numbered 14 in the Tree View), Teradata MS, or BAR server. For the location of
Node 2 in the cabinet, see “Example Cabinet Configurations” on page 21.
5
In the Connect dialog box, click Secure Shell (SSH). Click OK.
6
In the New Connection dialog box, click the SSH/SFTP tab, and for the Default Username
enter root.
7
Click OK.
8
At the command prompt, log in as root, a member of the tdtrusted group, or a user with
CNC privileges.
Teradata Data Warehouse Appliance 2690 Implementation Guide
239
Chapter 14: Maintaining the Database
Teradata Database Console Utilities
Using cnsterm to Run a Database Utility
Note: Because cnsterm is a command-line program, it allows access to only one CNS window
at a time.
1
At the Linux prompt on the control node, enter the following command to configure the
Teradata Database command-line environment:
tdatcmd
2
To start cnsterm to run a utility, enter:
cnsterm
The cnsterm prompt appears:
Input Supervisor Command:
>
This cnsterm prompt is actually the Supervisor window of CNS from which you can
launch database utilities.
3
At the prompt, start a utility. Preface the utility name with the CNS start command.
For example:
>start vprocmanager
4
The system displays a message similar to the following, indicating the available application
window in which the utility has been started:
Started 'vprocmanager' in window 1
at Thu Jul 23 11:53:10 2009
Up to four utilities can be run simultaneously. CNS starts each utility in a different
application window. If all application windows are occupied by running utilities, CNS will
not start another utility until one of the running utilities stops or is aborted.
5
From the control node command line, only one virtual window can be viewed at a time.
To display the Application Window in which the utility is running, and see the output
from the utility or to interact with the utility:
•
Use Ctl-C to exit the Supervisor Window.
•
At the Linux command prompt start cnsterm again, this time specifying the
application window in which the utility of interest is running. For example, enter the
following to display application window 1, in which the vprocmanager utility, started
in step 4, is running:
cnsterm 1
Use Ctrl-C combination exit any window and cnsterm n to open another.
Some utilities display information and stop automatically. Other utilities are interactive,
and have a number of commands that can be issued from the utility command prompt.
Interactive utilities must be explicitly stopped using the command that is appropriate to
the utility. This is most often either quit or quit; (quit followed by a semicolon).
When a utility has stopped running, either by itself because it is non-interactive or as a
result of an explicit quit command, use Ctrl-C to close the associated CNS application
window and return to the Linux command prompt.
Note: The Supervisor (main cnsterm) window can only be closed using Ctrl-C.
240
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Database Maintenance Tasks
Using cnscim to Check the Status of CNS Tasks
When CNS indicates that all four application windows are occupied by running utilities, it is
helpful to see what is running in each window. Use the cnscim program:
1
Open a Teradata Command Prompt. See “Logging on to the Control Node” on page 239.
2
At the Linux command prompt of the control node, enter:
cnscim -screens
3
cnscim returns output showing the status of each CNS window, for example:
Screen 1 -- vprocmanager
active=True, enabled fkeys=, help level=0,
nostop=False, reading=True, hide=True
Screen 5 -- DBS I/O
active=True, enabled fkeys=, help level=0,
nostop=False, reading=False, hide=False
Screen 6 -- SUPERVISOR
active=True, enabled fkeys=, help level=0,
nostop=False, reading=True, hide=False
Running Database Utilities from a Database Node
You can run PDE-level utility programs, for example, psh and pdestate from the command
line of any database node.
1
At the Linux command prompt, enter tdatcmd to set up the Teradata Database command
line environment.
2
On the command line, enter the following to start the utility:
utility_name [options]
where utility_name is the name of the utility, and options can include any of the
available command-line options and arguments for the utility.
Database Maintenance Tasks
All Teradata Data Warehouse Appliance 2690 customers receive a Teradata Core Support card
from the Teradata representative with delivery of the system. Be sure to follow the
recommended maintenance procedures listed on the card.
Note: Some of the core support maintenance recommendations are covered in detail this
publication.
The maintenance topics that follow are of two types:
•
•
Periodic maintenance tasks that should be done at regular intervals.
•
“Managing Accumulated Log Data” on page 242
•
“Verifying Data Block Integrity” on page 245
Additional maintenance tasks that only need to be performed occasionally
Teradata Data Warehouse Appliance 2690 Implementation Guide
241
Chapter 14: Maintaining the Database
Managing Accumulated Log Data
•
“Restarting the Teradata Database Software” on page 248
•
“Upgrading Teradata Software” on page 250
•
“Powering the System Off and On” on page 251
•
“Servicing Unplanned Power Outages” on page 259
Managing Accumulated Log Data
About Database Logs
Teradata Database contains a number of log tables that accumulate data, either automatically
or after certain features are enabled. Because log data grows over time, you must periodically
purge older information to avoid using up permanent space.
Logs
Description
Logs that can be purged manually or using Teradata Viewpoint. See “Deleting Old Log Data with
Teradata Viewpoint” on page 243.
Access Log
(DBC.AccLogTbl)
Data collected as defined in a BEGIN LOGGING statement, for each
privilege check of an attempted user access of a database object.
DBQ Logs:
Data collected during database query logging (DBQL), if DBQL is
enabled.
•
•
•
•
•
•
DBC.DBQLSummaryTbl
DBC.DBQLStepTbl
DBC.DBQLogTbl
DBC.DBQLObjTbl
DBC.DBQLExplainTbl
DBC.DBQLSqlTbl
Event Log
(DBC.EventLog)
Data collected automatically by the system for each user logon event.
ResUsage Logs:
ResUsage tables collect data on system resource usage.
•
•
•
•
•
•
•
•
•
•
•
You can enable ResUsage data collection and set the collection rate
using either:
DBC.ResUsageSpma
DBC.ResUsageSvpr
DBC.ResUsageShst
DBC.ResUsageIpma
DBC.ResUsageIvpr
DBC.ResUsageScpu
DBC.ResUsageSldv
DBC.ResUsageSawt
DBC.ResUsageSps
DBC.ResUsageSpdsk
DBC.ResUsageSvdsk
SWEvent Log
(DBC.SW_Event_Log)
242
• The ctl utility SCREEN RSS command
• Teradata Viewpoint data collectors
The collection rate determines how quickly data accumulates and
when the logs should be purged.
The system automatically inserts rows in response to software errors
and system events, for use by Teradata Customer Service.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Managing Accumulated Log Data
Logs
Description
TDWM Logs:
Logs for Teradata Viewpoint workload management functions.
• DBC.TDWMSummaryLog
• DBC.TDWMEventLog
• DBC.TDWMExceptionLog
Logs that must be purged manually purged
In Doubt transaction Log
(DBC.InDoubtResLog)
Contains a row for each transaction where completion was in doubt.
Note: Depending on site requirements, you may need to retain older data long after it should
be removed from an active log. If so, you can create backup log tables to store log history and
periodically copy data from the active logs to the backup tables. You can also archive copies of
the backup tables on tape for long-term reference.
Reference Information
Information on...
Is available in...
configuring access logging
Chapter 11: “Monitoring User Activity”
configuration and use of DBQL
Chapter 14: “Tracking Processing Behavior with
DBQL,” in Database Administration
using the ctl utility SCREEN RSS command
to set up ResUsage logging and log intervals
the SCREENRSS command in Chapter 8: “Control
GDO Editor (ctl), in Utilities Volume 1.
setting up Teradata Viewpoint data
collectors
“Enable the Data Collectors” in “Configure
Viewpoint to Monitor a Teradata Database,” in
Teradata Viewpoint Configuration Guide
Deleting Old Log Data with Teradata Viewpoint
Configure log data cleanup as follows:
1
From the Teradata Viewpoint main screen, select Admin>Teradata System.
2
To configure specific logs for clean up, and specify the cleanup interval:
a
In the SETUP column, select Log Table Clean Up.
b
In the TABLES column, select a log table category for cleanup, for example, DBQ Log.
c
Use default cleanup interval shown unless you have reason to change it.
Note: Coordinate the interval with your site requirements for storing log history.
3
d
Check the Enabled box.
e
Click the Apply button to activate the cleanup
To specify the time of day that all configured cleanup takes place:
Teradata Data Warehouse Appliance 2690 Implementation Guide
243
Chapter 14: Maintaining the Database
Managing Accumulated Log Data
a
From the SETUP column, select Clean Up Schedule.
b
Specify a time when the log tables are not active.
Note: The clean up operation locks the log table and delays logging in the table until
log data deletion is complete.
c
Check the Enabled box.
d
Click the Apply button to set the cleanup schedule.
Deleting Old Log Data Manually from System Tables
Before deleting old log data, determine whether you need to retain records of the data set for
deletion. For example, while Teradata recommends that you purge log data at least every 90 to
180 days, security policy for some sites may require retention of access log data for a much
longer time period.
Note: You cannot delete data that is less than 30 days old.
Use the following procedure when deleting old log data from system tables:
1
If your site requires long term retention of log data, do the following:
a
Create a duplicate log table in another database using the Copy Table syntax for the
CREATE TABLE statement.
CT DBC.tablename AS databasename.tablename
For further information on using the Copy Table syntax, see “Create Table” in SQL
Data Definition Language Syntax and Examples.
b
Back up the table to tape storage in accordance with your site back up policy.
Recommendation: Match the log backup/deletion schedule to the amount of log data
you want to maintain locally in system tables. For example, to maintain 90 days of log
data in a system table do the first back up at 120 days, then delete the last 30 days of
data in the log. Back up the log data every 30 days after that.
c
Drop the duplicate table using a DROP TABLE statement.
2
Log on to SQL Administrator as DBADMIN or another administrative user with DELETE
privileges on database DBC.
3
In the Query window, enter an SQL statement to purge old log entries. For example:
DELETE FROM DBC.object_name WHERE (Date - LogDate) > number_of_days ;
244
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Verifying Data Block Integrity
where:
Syntax Element
Description
object_name
The name of the DBC object that allows log deletions, as shown in
“About Database Logs” on page 242. For example, DeleteAccessLogV is
the delete object for the Access Log.
Date
SQL syntax element for the current date.
LogDate
The date contained in the LogDate column of the log view based on
the specified number_of_days from the current date.
number_of_days
The number of days of data that you want to retain in the system table;
the span of days from the current date to the oldest LOGDATE to be
retained.
Verifying Data Block Integrity
Routine system maintenance should include running SCANDISK and CheckTable monthly or
more frequently to check for data corruption in the file system and database:
•
SCANDISK checks the integrity of the Teradata Database file system. The file system keeps
track of all data stored in Teradata Database. SCANDISK inspects the low-level file system
data structures to ensure that the internal links between such structures are correct,
consistent, and reflect the proper ordering of the tables and rows in Teradata Database.
SCANDISK reports any problems it finds.
•
CheckTable checks the integrity of the tables stored in Teradata Database. It inspects the
table data structures, such as table headers, rows, and indexes to ensure that they are
properly formed, exist on valid AMP vprocs, and are consistent across the different
subtables that constitute a table (primary data, fallback data, and secondary indexes).
For periodic maintenance, Teradata recommends running SCANDISK immediately prior to
running CheckTable.
Running SCANDISK
SCANDISK is a command issued from within the Ferret utility.
Note: To use this procedure, you must have root access or the cns permission shown in “CNS
Permission Requirements” on page 238.
1
Log on to the control node as shown in “Logging on to the Control Node” on page 239.
2
Coordinate with the database administrator to determine an appropriate priority setting
for running SCANDISK. Running at a lower priority reduces the database performance
impact of the utility while users are on the system, but can increase the time required for
the scan.
Teradata Data Warehouse Appliance 2690 Implementation Guide
245
Chapter 14: Maintaining the Database
Verifying Data Block Integrity
Set the priority level under which SCANDISK will execute. For example, on the Database
Console command line, enter:
set priority=low
3
Disable script mode to enable the inquire and abort commands. On the Database Console
command line, enter:
disable script mode
4
Start SCANDISK with the following command on the Database Console command line:
scandisk
5
Enter y to indicate that SCANDISK should be started on all AMP vprocs. SCANDISK
begins verifying the integrity of file system data structures.
Note: SCANDISK can take a long time to check systems with large amounts of storage.
6
•
You can check the progress of SCANDISK at any time by entering inquire on the
Database Console command line.
•
You can stop SCANDISK at any time by entering abort on the Database Console
command line.
When SCANDISK has finished checking, it displays a message similar to the following:
72 of 72 vprocs responded with no messages or errors
7
Enter quit on the Database Console command line to exit Ferret.
If SCANDISK reports any errors, open a support incident with Teradata Customer Support at
https://tays.teradata.com, and attach a copy of the file containing the program output. For
more information on opening incidents, see “Opening an Incident” on page 59.
Running CheckTable at Level 2 for Database DBC
After running SCANDISK without errors, run CheckTable. CheckTable offers different levels
of checking. Higher-level checking is more thorough, but requires more time to run and uses
more system resources. Consequently, Teradata recommends that you initially run CheckTable
at a low level, and only run at a higher level of checking if problems are found at the lower
level of checking.
Note: To ruse this procedure, you must have root access or the cns permission shown in “CNS
Permission Requirements” on page 238.
1
Log on to the control node as shown in “Logging on to the Control Node” on page 239.
2
On the Database Console command line, type:
check dbc at level two concurrent mode;
Note: Be sure to include the semicolon at the end of the line.
If you are running CheckTable during a maintenance window, when there are no users on
the system, you can omit the concurrent mode option to speed up the check.
246
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Verifying Data Block Integrity
When CheckTable has finished checking, it presents a summary of the results, similar to:
156
156
0
15
0
0
3
table(s) checked.
fallback table(s) checked.
non-fallback table(s) checked.
table(s) bypassed due to being unhashed.
table(s) failed the check.
Dictionary error(s) were found.
If any tables fail the check, run CheckTable again at level three on those tables. This could
take some time, depending on the size and complexity of the tables.
Running CheckTable at Level 1 for Non-DBC Tables
1
On the Database Console command line, type:
check all tables exclude dbc at level one concurrent mode;
Note: Be sure to include the semicolon at the end of the line.
If you are running CheckTable during a maintenance window, when there are no users on
the system, you can omit the concurrent mode option to speed up the check.
When CheckTable has finished checking, it presents a summary of the results, similar to:
242 table(s) checked.
241 fallback table(s) checked.
1 non-fallback table(s) checked.
0 table(s) failed the check.
0 Dictionary error(s) were found.
2
If any tables fail the check, run CheckTable again at level three on those tables. This could
take some time, depending on the size and complexity of the tables.
3
Enter quit; on the Database Console command line to exit the CheckTable utility.
Remember to end the command with a semicolon.
If CheckTable finds any errors open a support incident with Teradata Customer Support at
https://tays.teradata.com. Attach a copy of the text file containing the program output. For
more information on opening incidents, see “Opening an Incident” on page 59.
Reference Information
Information on...
Is available in...
the CheckTable utility
“Checktable” in Utilities: Volume 1 (A-K)
the SCANDISK command
Teradata Data Warehouse Appliance 2690 Implementation Guide
247
Chapter 14: Maintaining the Database
Restarting the Teradata Database Software
Restarting the Teradata Database Software
Occasional database restarts are a part of the ongoing maintenance and management of
Teradata Database. Restarts can be initiated manually by an administrator or automatically by
the Teradata Database system itself.
Restart Type
Possible Reasons
Manual
•
•
•
•
Install patch upgrade to Teradata Database software
Finalize changes made to user tunable system configuration settings
Change to physical system configuration
Bring offline AMPs back online
Automatic
•
•
•
•
Error in database, application, or BYNET software
Failure in physical storage systems
Loss of power that causes nodes to reboot
Component failure in critical system hardware
As part of any restart process:
•
•
Teradata Database:
•
Informs logged on users of the restart, and terminates all database sessions.
•
Frees associated session resources, such as spool space.
•
Initiates database stop and startup processing.
•
Logs restart information.
•
Performs transaction recovery processing. Partially completed transactions are rolled
back.
PDE executes the various stages of the restart process.
Initiating a Manual Restart
The database is unavailable during the restart process, so you should schedule manual restarts
during times when database use is at a minimum, for example during periodic maintenance.
Notify users of manual restarts and advise them to log off the system.
For more information on scheduling periodic maintenance windows, see “Opening a
Maintenance Window” on page 57.
PDE executes restarts in stages. You can use the pdestate utility to monitor the status of the
system both before and during a restart.
1
Log on to the control node of the system, as described in “Logging on to the Control
Node” on page 239.
2
At the command line, enter:
psh pdestate -a
248
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Restarting the Teradata Database Software
Ideally, pdestate will indicate that no users are logged on to the system, and the system is
quiescent (idle), with a message similar to this:
all 4 nodes:
PDE state is RUN/STARTED.
DBS state is 5: Logons are enabled - The system is quiescent
Note: For more information about the psh and pdestate commands, see the man pages for
these utilities.
3
To initiate the restart process, at the command line enter:
tpareset -f reason
where reason is a required string that describes the reason for the restart, and is logged
with the restart event. The string cannot begin with a hyphen, and need not be enclosed in
apostrophes.
Enter y at the prompt to confirm you want to restart the database.
For more information on the tpareset command, see “TPAReset (tpareset)” in Utilities:
Volume 2 (L-Z).
4
To monitor the restart process as it goes through the various stages, run pdestate
periodically, as described in step 2.
5
If the database fails to return to a fully functional state, run the Vproc Manager utility as
described in “Troubleshooting Database Restarts” on page 250.
Reference Information
Information on...
Is available in...
the tpareset command
“TPAReset (tpareset)” in Utilities: Volume 2 (L-Z)
About Automatic Restarts
Teradata Database automatically restarts if certain problems are detected. Frequently the
restart resolves the problem, however, some problems persist across restarts, and can cause
repeated restarts.
You can track automatic restarts by monitoring the AWS Fault Viewer. To ensure the database
returns to a fully operational state, run the Vproc Manager utility as shown in
“Troubleshooting Database Restarts” on page 250. If system vprocs or nodes remain down or
offline, submit an incident to Customer Support using the Teradata @ Your Service website, as
described in “Opening an Incident” on page 59.
Note: The system saves a crashdump if it automatically restarts. The crashdump information
can be used by Teradata Support personnel to investigate software errors that cause restarts.
Make sure to allocate space for crashdumps, as described in “Assigning Perm Space to
Crashdumps” on page 85.
Teradata Data Warehouse Appliance 2690 Implementation Guide
249
Chapter 14: Maintaining the Database
Upgrading Teradata Software
Troubleshooting Database Restarts
After any database restart, do the following to verify that Teradata Database is fully functional:
1
From a Console Subsystem command line, as described in “Running Database Utilities
From Viewpoint” on page 237, start the Vproc Manager utility (vprocmanager) by
entering:
start vprocmanager
2
On the Vproc Manager command line enter:
status notonline
If the system is up and running properly, Vproc Manager displays:
SYSTEM NAME: system_name
current_date_time
All DBS vprocs are fully online.
All PDE nodes are fully online.
If any vprocs are not in an ONLINE state, Vproc Manager lists those vprocs. For example:
SYSTEM NAME: Teradata_app_1
09/09/14 14:38:04
DBS LOGICAL CONFIGURATION
------------------------Rcv
Jrnl/
Vproc Rel.
Node
Can
Crash Vproc
Config
Config Cluster/ Host VSS
Number Vproc# ID
Move Count State
Status
Type
Host No. Type Vproc
------ ------ ------ ----- ----- ------- -------- ------ -------- ----- ----5
6
2-14 Yes
0
OFFLINE Online
AMP
2
On
10237
-------------------------------------------------------------------------------DBS State: Logons are enabled - The system is quiescent
DBS RestartKind: COLD
All PDE nodes are fully online.
3
Exit Vproc Manager by entering quit on the Vproc Manager command line.
4
If you do not understand the reason for an automatic restart, or if the output from Vproc
Manager indicates an ongoing problem, submit an incident using the Teradata @ Your
Service website, as described in “Opening an Incident” on page 59.
Note: Before opening the incident, you can inspect the relevant portions of the system
event log, /var/log/messages, and attach a copy of those entries to the incident.
Upgrading Teradata Software
Teradata periodically releases software patches and maintenance upgrades to customers with
maintenance and support agreements. Information about patches and upgrades is available
from the Teradata @ Your Service website, at https://tays.teradata.com. Review the following
on a regular basis for valuable information, patches, and upgrades for your Teradata Database
release.
250
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
Interval
Items to Review at Teradata @ Your Service
Weekly
Tech Alerts and associated software patches
Monthly
Teradata Tools and Utilities client application patches and updates, as described in
Chapter 4: “Setting Up Teradata Clients”
Quarterly
Teradata Database software patch and maintenance releases
For more information on upgrading Teradata Database software, see the following
publications, which are available from http://www.info.teradata.com:
Publication Title
Publication Number
Teradata Database Upgrade Guide, Overview, and Preparation
B035-5921-049K
Upgrading Teradata Software (Maintenance): Linux SLES9 SP3, SLES10 SP1,
TD 6.2, 12.0, 13.0
B035-5920-049K
Parallel Upgrade Tool (PUT) for UNIX MP-RAS and Linux User Guide,
Release 3.04.06
B035-5712-049K
Powering the System Off and On
You may need to stop the database and shut down the system hardware due to a scheduled
power outage or when directed by a Customer Service Representative. The following
procedures describe the best practices for:
•
Stopping the database and removing power from all chassis in a system or cabinet
Note: During a power off, the chassis are powered off, but the cabinet AC boxes are still
receiving power from the grid.
•
Restoring power to all chassis in a system or cabinet and starting the database.
Powering Off All Chassis in a System or Cabinet
The following procedure should be used to shut down the Teradata Database and remove
power from all component chassis within a system or cabinet. The procedure does not remove
power from the cabinets.
1
Notify all users that the system is going to be powered off and that they should save all
work in progress and log off the system. Users include Teradata Database users and those
using Teradata Managed Server (TMS) and BAR applications.
2
Ensure the Teradata Database is not set to automatically start after nodes are rebooted.
a
Using a browser, open the PUT application. For more information, see the Parallel
Upgrade Tool (PUT) Reference.
Teradata Data Warehouse Appliance 2690 Implementation Guide
251
Chapter 14: Maintaining the Database
Powering the System Off and On
b
In the PUT screen, type the User Name and Password for the node, then press Enter.
c
In the Other operations drop-down list, select Set Teradata Startup Option.
d
From the Network Subnet Selection page, select the BYNET network, xx.xx.xx.xx
(byn0), then click Next.
e
When the Select Nodes page appears, move all the nodes from the Available list to the
Selected list, then click Next.
f
When the Select Teradata Startup Option page appears, select DO NOT automatically
start Teradata after a system reboot, then click Next.
g
From the Select Reboot Option page, select No, don’t reboot the nodes now, then click
Next.
h
Click Finish.
3
Access the database control node. See “Logging on to the Control Node” on page 239.
4
Check the status of the Teradata Database to make sure user activity is stopped by typing
the following, then press Enter:
pdestate -a
If the following message displays, the database is quiescent, has no users logged on, and
you can continue with the next step:
PDE state is RUN/STARTED.
DBS state is 5: Logons are enabled - The system is quiescent.
If the following message displays, users are logged on. You must ask them to log off, and
repeat this step (rerun pdestate -a):
PDE state is RUN/STARTED.
DBS state is 4: Logons are enabled - Users are logged on.
5
Shut down the Teradata Database, as follows:
a
In the node console window, type the following, then press Enter.
tpareset -x down for maintenance
b
Type Y to confirm that you want to shut down Teradata Database, then press Enter.
c
To verify that the Teradata Database has stopped, type the following, then press Enter.
psh pdestate -a
The system returns a message similar to the following:
# psh pdestate -a
all 2 nodes:
PDE state: DOWN/HARDSTOP
Note: If the system does not return this message on the first attempt, repeat the
command until the message is returned.
6
From Server Management Client, verify that the operational states of the chassis in the
cabinet or system have an OK status.
a
252
In the Tree View, select System, then select the View > Status command. The Status
window displays.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
7
b
In the Status window, if the Hide components that have normal operational states box is
checked, clear it.
c
For each cabinet, verify that the chassis icons are green in the Status window.
From Server Management Client, perform a controlled shutdown and power off of the
nodes, TMS servers, and BAR servers.
•
To shut down and power off the nodes and servers in one cabinet, select that cabinet in
the Tree View, then select the Functions > Power Off command.
•
To shut down and power off all the nodes and servers in the system, select System in
the Tree View, then select the Functions > Power Off command.
A Command Summary window displays to show the progress of the Power Off command.
When the command is running, the Status column displays In Progress. When the
command completes, the Status column displays Complete. For more information about
the window, see Server Management online Help.
8
9
From Server Management Client, verify that the nodes and servers are powered off.
a
In the Status window, if the Hide components that have normal operational states box is
checked, clear it.
b
For each cabinet, verify that the icons for the nodes and servers are black in the Status
window. A black icon indicates that the node or server is powered off.
Do one of the following:
•
•
To perform an orderly shutdown of an SWS VM and Viewpoint VM in a system or
cabinet that has VMSs:
i
Using Server Management Client, select the SWS VM and Viewpoint VM in the
Tree View.
ii
Select Functions > Power Off.
In a system or cabinet that has a physical SWS, perform an orderly shutdown of the
SWS by typing the following at an SWS command prompt:
init0
10 At the front of each processing/storage cabinet, verify that:
a
The LEDs on all processing nodes and servers, if present, are powered off.
b
The VMS power LEDs and status LEDs (upper right of each VMS chassis) are on.
Teradata Data Warehouse Appliance 2690 Implementation Guide
253
Chapter 14: Maintaining the Database
Powering the System Off and On
Power On/Off Button
Power LED
1
Status LED
!
2
Contol Panel
(front)
Node_0036
Note: The VMS is in position 12. See “Example Cabinet Configurations” on page 21 for
the location of the server management node in the cabinet.
11 At the front of each processing/storage cabinet, perform a graceful shutdown of each VMS.
a
Briefly (less than four seconds) press the power button on each VMS control panel.
b
Verify that each VMS is off.
A VMS is off when the power LED and all other LEDs except the status LED on its
control panel are off.
12 At the rear of each processing/storage cabinet, use both power switches to power off each
drive enclosure.
5HDU
3RZHU6ZLWFKHV
$UUD\B
13 At the front of each processing/storage cabinet, switch off all of the circuit breakers on each
orange and blue AC box.
The circuit breakers are off when the switches are in the down position. On some AC
boxes, the switches may be labeled with the word off, which is visible only when the
switches are in the down position.
Note: Switching the circuit breakers off removes power from the Ethernet switches.
254
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
%
$
%
%
$
7RS
7RS
%WP
%WP
$
%
$
3RZHUB
14 At the front of each processing/storage cabinet that has been powered off, verify that all
LEDs on the processing nodes, servers, VMSs, and drive enclosure chassis are off.
At this point, if you selected System in the Tree View, all chassis in all system cabinets are
powered off. If you selected one or more cabinets, all chassis in the selected cabinets are
powered off.
Powering On All Chassis in a System or Cabinet
1
%
At the front of each processing/storage cabinet, switch on all of the circuit breakers on each
orange and blue AC box.
$
%
%
$
7RS
7RS
%WP
%WP
$
%
$
3RZHUB
Note: It is not necessary to power on the VMSs. The VMSs, Ethernet switches, and KVM
power on automatically when the circuit breakers are switched on. It takes 5-10 minutes
for the VMSs to completely power on. Status for the VMSs and other chassis will not be
available until the VMSs have completely powered on.
2
At the rear of each processing/storage cabinet, use both power switches to power on each
drive enclosure. It takes approximately three minutes for the drive enclosures to power on
completely.
Teradata Data Warehouse Appliance 2690 Implementation Guide
255
Chapter 14: Maintaining the Database
Powering the System Off and On
5HDU
3RZHU6ZLWFKHV
3
$UUD\B
From Server Management Client, after allowing enough time for the VMSs to establish
communication with all chassis, verify that the VMSs and the drive enclosures are
operating normally before continuing.
a
If the Status window is not already displayed, in the Tree View, select System, then
select the View > Status command. The Status window displays.
b
If the Hide components that have normal operational states box is checked, clear it.
c
In the Status window, verify that the icon for each VMS is green.
This indicates the server management nodes have booted up and have an OK status in
the Tree View.
d
In the Status window, verify that the icon for each drive enclosure is green.
This indicates the drive enclosures have finished performing their power-on self-tests,
and that they have an OK status in the Tree View.
Caution:
If the icons for the VMS are not green, submit an incident to Customer Support using the
Teradata @ Your Service website, as described in “Opening an Incident” on page 59.
4
Use SYMplicity to place the disk arrays online.
a
From the SWS, open SYMplicity.
b
In the Enterprise Management window, select the Devices tab.
c
Double click the array where the offline controller is located (indicated by a red circle
with a down pointing arrow).
d
In the Array Management window, select the Physical tab.
e
Click the offline controller (indicated by a red circle with an "x").
f
Select Advanced > Recovery > Place Controller > Online.
g
When a confirmation dialog box appears, click Yes.
h
Allow approximately 3 minutes for the controller to come online.
When the controller is online, the seven segment display will show the tray ID.
256
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
Caution:
If the correct number of drive enclosures are not displayed, or their icons are not green,
submit an incident through Teradata @ Your Service.
5
From Server Management Client, power on the nodes, TMSs, and BAR servers:
a
To power on the nodes and servers in one cabinet, select that cabinet in the Tree View,
then select the Functions > Power On command.
b
To power on all the nodes and servers in the system, select System in the Tree View,
then select the Functions > Power On command.
A Command Summary window displays to show the progress of the Power Off command.
When the command is running, the Status column displays In Progress. When the
command completes, the Status column displays Complete. For more information about
the window, see Server Management online Help.
Wait approximately 5-10 minutes for all nodes to boot.
6
From Server Management Client, use the Status window to verify that all components are
powered on and operating normally.
The icons for all the chassis in each cabinet must be green, which means they have an OK
status in the Tree View.
Caution:
If the icons for all the chassis in the cabinet are not green, submit an incident through Teradata
@ Your Service.
7
8
If you used the Teradata Parallel Upgrade Tool (PUT) to change the Set Teradata Start
Option to DO NOT start the database, use PUT to change the Set Teradata Start Option back
to Start the Database.
a
Using a browser, open the PUT application. For more information, see the Parallel
Upgrade Tool (PUT) Reference.
b
In the PUT screen, type the User Name and Password for the node, then press Enter.
c
In the Other operations drop-down list, select Set Teradata Startup Option.
d
From the Network Subnet Selection page, select the BYNET network, xx.xx.xx.xx
(byn0), then click Next.
e
When the Select Nodes page appears, move all the nodes from the Available list to the
Selected list, then click Next.
f
When the Select Teradata Startup Option page appears, select Automatically Start
Teradata after a system reboot, then click Next.
g
From the Select Reboot Option page, select No, don’t reboot the nodes now, then click
Next.
h
Click Finish.
If there are no problems encountered during the power on, start the Teradata Database.
a
In the Server Management Client Tree View, select the lowest-numbered node in the
lowest-numbered cabinet. Do not select a VMS, TMS, or BAR server. For the location
of lowest-numbered node in the cabinet, see “Example Cabinet Configurations” on
page 21.
Teradata Data Warehouse Appliance 2690 Implementation Guide
257
Chapter 14: Maintaining the Database
Powering the System Off and On
b
Click Functions > Connect.
c
On the Connect dialog box, select Console, then click Ok.
d
On the New Connection dialog box, click Ok.
A console window for the node displays.
e
Log on as root and provide the password.
The Teradata Command Prompt appears.
f
Verify that the nodes are connected to both BYNET networks (BYNET0 and BYNET1).
At the Teradata Command Prompt, type the following, then press Enter:
bam -s
•
For a Teradata Data Warehouse Appliance 2690 system with two nodes, the
following message should display:
Net #
0
1
•
Nodes
2
2
Routes
2
2
Net name
eth2
eth3
For a Teradata Data Warehouse Appliance 2690 system with four nodes, the
following message should display:
Net #
0
1
Nodes
4
4
Routes
4
4
Net name
eth2
eth3
Where:
g
•
Net # is the number of the BYNET network (0 or 1)
•
Nodes is the number of nodes currently connected to the network in the Teradata
Data Warehouse Appliance 2690 system
•
Routes is the is the current number of network routing paths (usually one routing
path per node)
•
Net name is the network interface name
Verify that all the pdisks on all the nodes are good.
i
At the Teradata Command Prompt, type the following, then press Enter:
psh verify_pdisks
ii
Wait for the following message to appear:
All pdisks on this node verified
Caution:
If this message does not appear, submit an incident through Teradata @ Your Service.
h
Type the following to verify that the database is down, then press Enter:
psh pdestate
The following message should display:
PDE state is DOWN/HARDSTOP
i
Type in the following command to start Teradata Database and press Enter:
/etc/init.d/tpa start
258
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 14: Maintaining the Database
Servicing Unplanned Power Outages
j
Type the following and press Enter:
psh pdestate -a
The following message should display:
PDE state is RUN/STARTED.
DBS state is 5: Logons are enabled - The system is quiescent.
Note: Depending on the size of the Teradata database, it may take several minutes
before the command returns this message. If the system does not return it on the first
attempt, repeat the psh pdestate -a command until the message is returned.
9
Use vprocmanager to verify that all vprocs have started.
a
At the Teradata command prompt, type the following and press Enter:
tdatcmd
b
Type the following, then press Enter:
vprocmanager
c
At the vprocmanager command prompt, type the following, then press Enter:
status notonline
d
In the output, verify that the following message displays:
All DBS vprocs are fully online
All PDE nodes are fully online
If the message does not display, submit an incident through Teradata @ Your Service.
For more information about troubleshooting a database start, and for information
about gathering supporting information, such as console log error codes, for the
purpose of submitting an incident to Customer Support, see “Troubleshooting
Database Restarts” on page 250.
Servicing Unplanned Power Outages
In the event of an unplanned power outage:
•
Submit an incident to Customer Support using the Teradata @ Your Service website, as
described in “Opening an Incident” on page 59.
•
Do not restart the database. With the help of Customer Support, perform a full system
power on sequence, as described in “Powering On All Chassis in a System or Cabinet” on
page 255.
Teradata Data Warehouse Appliance 2690 Implementation Guide
259
Chapter 14: Maintaining the Database
Checkpoint
Checkpoint
Before leaving this chapter, make sure that:
√
Result
Reference
You know the various methods for running
console utilities.
“Running Database Utilities From
Viewpoint” on page 237.
You have a procedure for regularly purging
accumulated log data.
“Managing Accumulated Log Data” on
page 242.
You regularly check for data corruption in the
database and file system.
“Verifying Data Block Integrity” on
page 245.
You know how to restart Teradata Database
software.
“Restarting the Teradata Database
Software” on page 248.
You know when to upgrade Teradata software
and how to request assistance from Teradata
Customer Service.
“Upgrading Teradata Software” on
page 250.
You know how to stop the database and shut
down the system hardware. You also know how
to restore power and restart the database.
“Powering the System Off and On” on
page 251.
You know what to do in the event of an
unplanned system outage.
“Servicing Unplanned Power Outages”
on page 259.
If you do not have these results, return to the section in the Reference column and review that
procedure.
260
Teradata Data Warehouse Appliance 2690 Implementation Guide
CHAPTER 15
Moving Data To and From
Teradata Database Tables
This chapter shows how to set up, create, run and troubleshoot, simple data movement jobs
using Teradata Parallel Transporter (TPT) easy scripting. For instructions on creating more
complex TPT job scripts, see Teradata Parallel Transporter User Guide.
Although TPT is the preferred data movement utility, you can also use the BTEQ utility to do
some data movement tasks. See Appendix B: “Loading and Updating Tables with BTEQ.”
Data Movement Task Overview
•
“Setting Up the Global Job Variables File” on page 265.
•
“Loading a Data From an External ODBC Database” on page 266.
•
“Loading Data from an External Flat File” on page 271.
•
“Exporting Data to an External Flat File” on page 275.
•
“Launching a Teradata PT Job” on page 278.
•
“Monitoring and Managing a Teradata PT Job” on page 279.
•
“Evaluating a Completed Teradata PT Job” on page 280.
•
“Troubleshooting a Failed Job” on page 281.
About Teradata Parallel Transporter
TPT job scripts use coded elements called “operators” to move data from a source to a
destination (target).
Data
Source
Reads
Data
Producer
Operator
Data
Stream
Consumer
Operator
Writes
Data
Data
Destination
1195-001A
Teradata Data Warehouse Appliance 2690 Implementation Guide
261
Chapter 15: Moving Data To and From Teradata Database Tables
About Teradata Parallel Transporter
About TPT Easy Job Scripting
A TPT easy job script defines only the main job elements and overall job flow, using defaults
and shortcuts to simplify job script creation. Easy scripting is suitable for most simple data
movement tasks. For more complex jobs, you can use the full TPT scripting language (similar
to SQL) to modify the easy script examples.
A TPT easy job script uses this basic format:
DEFINE JOB job_name
(
APPLY dml TO OPERATOR ($consumer_operator_name)
SELECT * FROM OPERATOR ($producer_operator_name);
);
where:
TPT Job Element
Description
DEFINE JOB job_name
The name of the job. Use a descriptive name, for example,
Load_Daily_Transactions.
APPLY dml
The operation to perform on the target, for example, $INSERT.
TO OPERATOR
($consumer_operator_name)
The operator that writes data. Operators that write to Teradata
Database include:
• $LOAD
• $UPDATE
• $INSERTER
• $STREAM (optional, if purchased)
Operators that write to an external flat file include:
• $DATACONNECTOR_CONSUMER or $FILE_WRITER
SELECT * FROM OPERATOR
($producer_operator_name)
Specifies only the producer operator that reads data from the
source, but is not an SQL SELECT statement. You must create
the SELECT statement using the producer operator SelectStmt
attribute. Operators that read data from external sources include:
• $ODBC operator (external ODBC table data)
• $DATACONNECTOR_PRODUCER or $FILE_READER (flat
file data)
Operators that read data from Teradata Database include:
• $EXPORT or $SELECTOR
Related Information
262
Information on...
Is available in...
all TPT operators and attributes, with usage notes
Teradata Parallel Transporter Reference
TPT scripting options and strategies
Teradata Parallel Transporter User Guide
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
About Teradata Parallel Transporter
Information on...
Is available in...
simple practice scripts you can launch and observe
Teradata Parallel Transporter Quick Start Guide
TPT Job Variables
Teradata recommends that you set up job variables files to define detailed job parameters.
The default TPT operators are defined with all operator attributes set to @job_variable_name,
where the job_variable_name corresponds to the attribute name. This causes the system to
look for the attribute value in the job variables files. If you do not set up an operator attribute
as a job variable, the system uses the default value, if a default exists.
Note: The default operator template definitions, which include the attribute list and
corresponding job variable names, in the TPT install directory, for example, on Windows:
C:/Program Files/Teradata/Client/client_version/Teradata Parallel Transporter/Templates
There are three places where you can specify operator attribute values by job variable name.
Job Variables Location
Description
Global job variables file
Stores attribute values common to all jobs, for example system name,
username, and password.
All jobs automatically check the global variables file for applicable
attribute values.
See “Using Global Job Variables” on page 264.
Local job variables file
Stores job-specific attribute values, such as file name, delimiter, or
target table.
A local variable value overrides a corresponding global variable value.
Each sample job in this chapter provides instructions for setting up the
local job variables file to define operator attribute values for the job. For
example, see “Defining the Local Job Variables” on page 267.
To use a local job variables file, specify the file name when launching the
job. See “Launching a Teradata PT Job” on page 278.
Command line variables
To avoid revising job scripts or job variables files, you can also specify
job variable values (for example, last-minute value changes) on the
command line, when launching a job.
Job variables specified on the command line override corresponding
global or local variables.
See “Launching a Teradata PT Job” on page 278.
Teradata Data Warehouse Appliance 2690 Implementation Guide
263
Chapter 15: Moving Data To and From Teradata Database Tables
About TPT Configuration Files
Related Information
For information about...
See...
scripting options beyond the easy scripting
examples shown in this chapter
Teradata Parallel Transporter User Guide
operators, including required
Teradata Parallel Transporter Reference
About TPT Configuration Files
The TPT configuration files are automatically shared by all jobs.
Configuration File
Purpose
Global Job
Variables file
Contains global variable values that can be used by many jobs.
See Using Global Job Variables.
Checkpoint
directory
These directories are set up by default when installing TPT, for example on
Windows, in C:/Program Files/Teradata/Client/client_version/Teradata
Parallel Transporter. TPT automatically writes information to the logs as a job
runs. The information can be useful in troubleshooting a failed job.
Logs directory
• The Checkpoint directory contains job logs indicating whether a job passes
various default and user-defined checkpoints.
• The Logs directory contains a public log information about each job and
the operators within the job. You can alternately specify a private (separate)
log within the Logs directory for each operator when defining job variables.
Using Global Job Variables
A global variables file is not required, but the file may be useful for specifying commonly used
operator attribute values. The following table lists operator attributes that are often specified
as global job variables. You can specify other attributes as global variables if needed.
Affected Operators
Job Variable Name
Description
Operators that read
from Teradata
Database, for example:
SourceTdpId
The name of the Teradata Database system from
which the operator exports, for example,
TDATSys1.
• Export operator
SourceUserName
The name and password for a Teradata Database
user with SELECT privileges on tables accessed by
TPT jobs.
SourceUserPassword
SourceAccountId
264
The account assigned to the SourceUser. A
portion of the account string prioritizes the job.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Using Global Job Variables
Affected Operators
Job Variable Name
Description
Operators that write
to Teradata Database,
for example:
TargetTdpId
The name of the Teradata system to which the
operator loads data, for example, TdatSys1.
TargetUserName
The name and password for a Teradata Database
user with INSERT/UPDATE?DELETE privileges
on tables accessed by TPT jobs.
• Load operator
• Update operator
Operators that read
from an external
ODBC-compliant
database, for example:
• ODBC operator
TargetUserPassword
TargetAccountId
The account assigned to the TargetUser. A portion
of the account string prioritizes the job
ODBCDSNname
The name used to identify the ODBC data source
in “Setting Up an External ODBC Data Source”
on page 73.
ODBCUserName
The name and password for a valid user of the
ODBC data source, having SELECT privileges on
tables accessed by TPT jobs.
ODBCUserPassword
Operator attributes used by your TPT jobs which are not specified in the global job variables
file should be specified as local job variables. If you do not setup an operator attribute as a job
variable, the system uses the default value, if a default exists.
Setting Up the Global Job Variables File
1
Navigate to the twbcfg.ini file in the TPT installation directory. For example, on Windows
clients:
C:/Program Files/Teradata/Client/client_version/Teradata Parallel Transporter
2
Open the twbcfg file. Notice that the Checkpoint and Logs directories already exist.
3
On the next available line in the twbcfg, specify the location of the global job variables file.
For example, to locate the file in the main TPT directory, enter:
GlobalAttributeFile='C:\Program Files\Teradata\client\14.00\Teradata Parallel
Transporter/GlobalJobVariables'
Note: You can change the location of any of the configuration files in the twbcfg if
required by site policy, but if you must remember to move the directory to that location.
4
Create the GlobalJobVariables directory in the specified location.
5
Using Notepad or other text editor, use job variable names to specify values for commonly
used operator attributes. A job variable name can appear only once in the file.
a
Copy the preset job variable name, for example, @SourceTdpId.
b
Remove the @ sign and set the variable name value for your system.
c
Repeat for all attributes you want to define as global variables, for example:
SourceTdpId
,SourceUserName
,SourceUserPassword
,SourceUserAccountId
,TargetTdpId
,TargetUserName
Teradata Data Warehouse Appliance 2690 Implementation Guide
=
=
=
=
=
=
'tdpid'
'tdusername'
'tdpassword'
'account_id'
'tdpid'
'tdusername'
265
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
,TargetUserPassword
,TargetUserAccountId
,ODBCDSNname
,ODBCUserName
,ODBCUserPassword
d
=
=
=
=
=
'tdpassword'
'account_id'
'odbc_dsnname'
'odbc_username'
'odbc_password'
Save the file to the GlobalJobVariables directory as GlobalJobVariables.txt.
Note: If required you can add new entries later, starting on the next available line.
Loading a Data From an External ODBC
Database
The following figure illustrates loading data from an ODBC-compliant database into a
Teradata Database table using Teradata PT producer and consumer operators.
Oracle
Database
Read
Data
ODBC
Operator
Data
Stream
Producer
Operator
Load
Operator
Consumer
Operator
Write
Data
Teradata
Database
2550A002
Usage Notes for Loading a Teradata Table
DataDirect drivers must be installed and configured on each client from which TPT jobs are
run. See “Setting Up an External ODBC Data Source” on page 73.
The target table must exist in Teradata Database and must:
•
Be empty
•
Have no join indexes, hash indexes, or secondary indexes
•
Have no foreign keys
For information on converting tables in an ODBC-compliant database to Teradata tables, see
“Converting Existing Database Tables to Teradata Tables” on page 107.
The database that owns the destination table must have enough perm space for the data.
Creating the Job Script
1
Use Notepad or another text editor to create the job script, using the easy scripting format
and standard operator definitions ($LOAD and $ODBC). For example:
DEFINE JOB job_name
(
APPLY $INSERT TO OPERATOR ($LOAD)
SELECT * FROM OPERATOR($ODBC);
);
266
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
Note: The example job script specifies the standard TPT DML insert macro, $INSERT.
The $INSERT macro causes TPT to automatically generate an insert statement based on
the Load operator TargetTable attribute. If you need a more complex INSERT statement,
for example, to use a CASE statement, you must create the full DML INSERT statement.
See “Coding the Executable Section” in Teradata Parallel Transporter User Guide.
2
Save the file as job_name.txt to a directory set up for similar jobs, for example (Windows):
C:/Program Files/Teradata/Client/client_version/Teradata Parallel Transporter/Load_Jobs
Defining the Local Job Variables
Using a TPT easy job script requires that you also define job variable values for certain
common operator attributes in a local job variables file.
Variables already specified in the Global Job Variables file need not be specified again in the
local job variables file unless you want to change the values. Local job variable values override
the corresponding global variables when the job runs.
Note: Your job may benefit from the use of additional operator attributes not shown for this
step. See “Load Operator” and “ODBC Operator” in Teradata Parallel Transporter Reference.
1
Identify the Load operator attributes you want to use for the job and define values for the
corresponding job variable names. The following table shows the job variable names for
commonly used $LOAD attributes.
Load Operator
Job Variable Name
TargetTdpId
TargetUserName
TargetUserPassword
TargetAccountId
WorkingDatabase
Job Variable Value
Values for these variables may have already been specified in the
global job variables file, and only need to be specified in local job
variables file if you want to override the global values.
See “Setting Up the Global Job Variables File” on page 265 for
specification instructions.
Normally, the name of the database where the TargetTable is located.
Specifying a WorkingDatabase eliminates the need to fully qualify the
name for TargetTable, and ensures that ErrorTable1, ErrorTable2, and
LogTable are located in the same database as TargetTable.
TargetTable
The name of the Teradata Database table being loaded.
Teradata Data Warehouse Appliance 2690 Implementation Guide
267
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
Load Operator
Job Variable Name
ErrorTable1
Job Variable Value
The name of a table that contains a list of records that were not
processed for a job because of certain acquisition phase errors:
• Data conversion errors
• Constraint violations
• AMP configuration
You cannot use a name that duplicates an existing table unless you are
restarting a paused Load operator job.
If you specify a name, the system creates ErrorTable1 in the default
database for the logon user, unless a different database is specified for
the WorkingDatabase attribute.
If you do not specify a name, the system default name for ErrorTable1
is based on the TargetTable name. The system names the table using
the form ttname_ET, and creates the table is in the database that
contains TargetTable, unless a different database is specified in the
WorkingDatabase attribute.
ErrorTable2
The name of a table that contains a list of records that violated the
unique primary index constraint for the TargetTable.
You cannot use a name that duplicates an existing table unless you are
restarting a paused Load operator job.
If you specify a name, the system creates ErrorTable2 in the default
database for the logon user, unless a different database is specified in
the WorkingDatabase attribute.
If you do not specify a name, the system default name for ErrorTable2
is based on the TargetTable name. The system names the table using
the form ttname_UV, and creates the table is in the database that
contains TargetTable, unless a different database is specified in the
WorkingDatabase attribute.
LogTable
The name of the restart log table that contains checkpoint data which
can be used in restarting a job.
The log table name must not duplicate t an existing table name.
The system automatically creates the log table in the default database
for the TargetUserName unless you specify a database name as the
value for the WorkingDatabase attribute.
LoadPrivateLogName
The name of a file in Logs directory to which the system writes job
information specific to the Load operator, for example, LoadLog.
The specified name appears as a file in the public log.
If no private log name is specified, the log is stored in the public log.
For additional information and usage notes for Load operator attributes, see the chapter
on Load operator in Teradata Parallel Transporter Reference.
2
268
Identify the attributes you want to use for the producer operator and assign values to the
corresponding job variable names. Commonly used attributes for $ODBC operator are:
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
$ODBC Operator
Job Variable Name
Job Variable Value
ODBCDSNname
The DSNname of the ODBC source system, for example, OracleSys.
The DSNname is not required if it was already specified in the Global
Job Variables file.
ODBCUserName
The name of a valid user for the ODBC source system, who has
SELECT privileges on the source table specified in SelectStmt.
ODBCUserPassword
The password for the user specified by UserName.
ODBCPrivateLogName
The name of a file in the Logs directory that contains additional
detailed job run information, specific to the $ODBC operator, which
is not found in the public log. For example, ODBCLog.
Public logs can be useful in determining the causes of job failure.
ODBCSelectStmt
The SQL SELECT statement that defines the ODBC data source and
the columns the $ODBC operator should read. For example:
SELECT * FROM databasename.tablename;
or if you are selecting a subset of available tablename columns,
SELECT
column_name1,
column_name2,
...
FROM databasename.tablename;
ODBCTruncateData
Instructs the system how to handle source data strings that are too
large to fit into the target table column.
For an explanation, see “Handling Truncated Data” on page 270.
3
Use Notepad or other plain text editor to create a list of job variables as described in step 1
and step 2, setting the actual values for your system, for example:
TargetTdpId
=
,TargetUserName
=
,TargetUserPassword
=
,TargetAccountId
=
,TargetWorkingDatabase=
,LoadPrivateLogName
=
,TargetTable
=
,ErrorTable1
=
,ErrorTable2
=
,LogTable
=
,ODBCDSNname
=
,ODBCPrivateLogName
=
,ODBCUserName
=
,ODBCUserPassword
=
,ODBCTruncateData
=
,ODBCSelectStmt
=
'tdpId'
'tdusername'
'tdpassword'
'account_id'
'database_name'
'loadlog'
'target_table_name'
'jobname_E1'
'jobname_E2'
'jobname_logtable'
'DSNname'
'odbclog'
'odbcusername'
'odbcpassword'
'No'
'Select * FROM databasename.tablename;'
Note: Operator job variable names are shown in the order the operators appear in the job
script, but this arrangement is not required.
4
Save the job variables file as job_nameVar.txt, to the directory that contains the job script.
Teradata Data Warehouse Appliance 2690 Implementation Guide
269
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
Note: For information on running a job, see “Launching a Teradata PT Job” on page 278.
Usage Considerations When Importing Data From an ODBC Database
Consider the following topics when importing data from an ODBC database into Teradata.
Handling Truncated Data
ODBC-compliant databases, for example Oracle or IBM DB2, sometimes contain column
data types that may not be compatible with Teradata. For example, the maximum size of the
IBM DB2 column type LONG, which is equivalent to a Teradata VARCHAR column, is 2 MB.
The maximum VARCHAR column size is 64000 bytes.
You can load data from a LONG column data source if the data does not exceed the Teradata
VARCHAR 64000 byte limit. Use the TruncateData attribute for the ODBC operator to specify
whether any source data that does exceed the limit should be truncated to fit into the
corresponding Teradata column or to skip the operation for that row and return an error.
The TruncateData attribute values are:
•
'Yes' (or 'Y') = truncate data (default)
•
'No' (or 'N') = do not truncate data
Handling DATE Fields
On some non-Teradata databases the Date field does not equate to a Teradata DATE data type.
An Oracle DATE field is equivalent to the Teradata TIMESTAMP data type, which has a
format of YYYY-MM-DD HH:MM:SS and is equivalent to CHAR(19). The Teradata DATE
data type in ANSI date form has a format of YYYY-MM-DD (equivalent to CHAR(10)).
Whether the TruncateData attribute is set to Yes or No, the ODBC operator truncates the
conversion of an Oracle Date field to a Teradata DATE data type. To avoid truncation when
converting Oracle Date information, the data type for the Teradata column must be
TIMESTAMP or CHAR(19).
Handling DECIMAL Data
When running a load job from a Windows client to import DECIMAL data from nonTeradata Databases (for example, Oracle) and moving it to Teradata Database, you may
encounter varying results depending on several data factors:
270
•
If the precision values between the source and target tables are not equal, the data is
checked at runtime. If the data does not fit, the job is terminated.
•
If the scale factors do not match, one of the following happens:
•
If the source scale factor is less than the target, then Teradata PT adds 0’s (zeros) to the
end of the source scale factor until they do match, and then the job continues.
•
If the source scale factor is greater than the target, the job terminates before attempting
to process the data, due to possible loss of data.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Loading Data from an External Flat File
•
For source column NUMBER (m, n) and target column DECIMAL (M, N), the job does
the following:
•
Terminates with error if n>N
•
Runs if n<N or n=N
•
Runs if m<=M, assuming n<N or n=N
•
Attempts to run if m>M, assuming n<N or n=N
Loading Data from an External Flat File
The following figure illustrates how TPT loads data from an external flat file into a Teradata
Database table using $DataConnector (producer) and $Load (consumer) operators.
Flat
File
Read
Data
DataConnector
Operator
Data
Stream
Producer
Operator
Load
Operator
Write
Data
Teradata
Database
Consumer
Operator
2550A004
Usage Notes for Loading a Teradata Table
DataDirect drivers must be installed and configured on each client from which TPT jobs are
run. See “Setting Up an External ODBC Data Source” on page 73.
The target table exists in Teradata Database and:
•
Is empty
•
Has no join indexes, hash indexes, or secondary indexes
•
Has no foreign keys
Note: To insert data into a populated table, use the Update operator ($UPDATE). Operator
attribute specification for $UPDATE using job variables is similar to the $Load operator
shown in this job example. For information on creating an update job, see Teradata Parallel
Transporter User Guide.
Make sure the target table has enough perm space to contain the data being loaded.
Investigate possible data conversion issues which may result form Teradata data type
requirements.
Teradata Data Warehouse Appliance 2690 Implementation Guide
271
Chapter 15: Moving Data To and From Teradata Database Tables
Loading Data from an External Flat File
Creating the Job Script
1
Use Notepad or another text editor to create the job script, using the easy scripting format
and standard operator definitions ($LOAD and $FILE_READER). For example:
DEFINE JOB job_name
(
APPLY $INSERT TO OPERATOR ($LOAD)
SELECT * FROM OPERATOR($FILE_READER);
);
Note: The example job script specifies the standard TPT DML insert macro, $INSERT.
The $INSERT macro causes TPT to automatically generate an insert statement based on
the Load operator TargetTable attribute. If you need a more complex INSERT statement,
for example, to use a CASE statement, you must create the full DML INSERT statement.
See “Coding the Executable Section” in Teradata Parallel Transporter User Guide.
See “Coding the Executable Section” in Teradata Parallel Transporter User Guide.
2
Save the file as job_name.txt to the directory set up for this and similar jobs, for example,
on Windows:
C:/Program Files/Teradata/Client/client_version/Teradata Parallel Transporter/Load_Jobs.
Defining the Local Job Variables
A TPT easy job script that loads data from an external flat file to a Teradata Database table
normally defines job variable values for certain operator attributes, as shown in the following
procedure.
Note: Your job may benefit from the use of other available operator attributes. See the
chapters on Load operator and ODBC operator in Teradata Parallel Transporter Reference.
1
Identify the Load operator attributes you want to use for the job and define values for the
corresponding job variable names. Commonly used attributes for Load operator are:
Load Operator
Job Variable Name
TargetTdpId
TargetUserName
TargetUserPassword
TargetAccountId
WorkingDatabase
Job Variable Value
Values for these variables may have already been specified in the
global job variables file. If so, they only need to be respecified in local
job variables file if you want to change values.
See “Setting Up the Global Job Variables File” on page 265 for
specification instructions.
Normally, the name of the database where the TargetTable is located.
Specifying a WorkingDatabase eliminates the need to fully qualify the
name for TargetTable, and ensures that ErrorTable1, ErrorTable2, and
LogTable are located in the same database as TargetTable.
TargetTable
272
The name of the Teradata Database table being loaded.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Loading Data from an External Flat File
Load Operator
Job Variable Name
ErrorTable1
Job Variable Value
The name of a table that contains a list of records that were not
processed for a job because of certain acquisition phase errors:
• Data conversion errors
• Constraint violations
• AMP configuration
You cannot use a name that duplicates an existing table unless you are
restarting a paused Load operator job.
If you specify a name, the system creates ErrorTable1 in the default
database for the logon user, unless a different database is specified in
the WorkingDatabase attribute.
If you do not specify a name, the system default name for ErrorTable1
is based on the TargetTable name. The system names the table using
the form ttname_ET, and creates the table is in the database that
contains TargetTable, unless a different database is specified in the
WorkingDatabase attribute.
ErrorTable2
The name of a table that contains a list of records that violated the
unique primary index constraint for the TargetTable.
You cannot use a name that duplicates an existing table unless you are
restarting a paused Load operator job.
If you specify a name, the system creates ErrorTable2 in the default
database for the logon user, unless a different database is specified in
the WorkingDatabase attribute.
If you do not specify a name, the system default name for ErrorTable2
is based on the TargetTable name. The system names the table using
the form ttname_UV, and creates the table is in the database that
contains TargetTable, unless a different database is specified in the
WorkingDatabase attribute.
LogTable
The name of the restart log table that contains checkpoint data which
can be used in restarting a job.
The log table name must not duplicate t an existing table name.
The system automatically creates the log table in the default database
for the TargetUserName unless you specify a database name as the
value for the WorkingDatabase attribute.
LoadPrivateLogName
The name of a file in Logs directory to which the system writes job
information specific to the Load operator, for example, LoadLog.
If no private log name is specified, the log is stored in the public log.
For additional information and usage notes for Load operator attributes, see the chapter
on Load operator in Teradata Parallel Transporter Reference.
Teradata Data Warehouse Appliance 2690 Implementation Guide
273
Chapter 15: Moving Data To and From Teradata Database Tables
Loading Data from an External Flat File
2
Identify the attributes you want to use for the producer operator and assign values to the
corresponding job variable names. Commonly used attributes for $File_Reader are:
$File_Reader
Job Variable Name
Job Variable Value
SourceFileName
The fully qualified name of the flat file that the operator reads, for
example, a Windows pathname.
SourceFormat
The format of the SourceFile, which can be any of the following values:
• 'Delimited' = in text format with each field separated by a delimiter
character. When you specify Delimited format, you can use the
optional TextDelimiter attribute to specify the delimiter character.
The default is the pipe character ( | ).
Note: The fields specified for this attribute must use the VARCHAR
data type. Non-VARCHAR specifications result in an error.
• 'Binary': A 2-byte integer, n, followed by n bytes of data.
• 'Formatted' = both prefixed by a record-length marker and followed
by an end-of-record marker.
• 'Text' = character data separated by an end-of-record (EOR) marker.
• 'Unformatted' = not formatted. The data has no record or field
delimiters and must be specified using a Teradata PT schema.
For details about using formats other than 'Delimited', see
“DataConnector Operator” in Teradata Parallel Transporter Reference.
SourceTextDelimiter
The delimiter used in the SourceFile, for example, '|' (default) or ',' .
To use the tab character as a delimiter, use uppercase'TAB', not 'tab'.
Note: If a character used as a delimiter also appears as part of the data,
it must be preceded by a backslash character. For example, when a
comma delimited flat file includes an address field that allows commas,
the address must appear in the form: Los Angeles\, California
OpenMode
3
The access mode ('read' or 'write'). The value for $File_Reader is 'read'.
Use Notepad or other plain text editor to create the job variables file and set the attribute
values for the variables as described in step 1 and step 2, for example:
TargetTdpId
=
,TargetUserName
=
,TargetUserPassword
=
,TargetAccountId
=
,TargetWorkingDatabase=
,LoadPrivateLogName
=
,TargetTable
=
,ErrorTable1
=
,ErrorTable2
=
,LogTable
=
,SourceFileName
=
,SourceFormat
=
,SourceTextDelimiter =
,OpenMode
=
274
'tdpId'
'tdusername'
'tdpassword'
'account_id'
'database_name'
'loadlog'
'target_table_name'
'jobname_E1'
'jobname_E2'
'jobname_logtable'
'flatfile_name'
'delimited'
'|'
'read'
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Exporting Data to an External Flat File
Note: Operator job variable names are shown in the order the operators appear in the job
script, but this arrangement is not required.
4
Save the job variables file as job_nameVar.txt, to the directory that contains the job script.
For information on running a job, see “Launching a Teradata PT Job” on page 278.
Exporting Data to an External Flat File
The following figure illustrates how TPT export is data from a Teradata Database table to an
external flat file.
Flat
File
Write
Data
DataConnector
Operator
Data
Stream
Consumer
Operator
Export
Operator
Producer
Operator
Read
Data
Teradata
Database
2550A003
Usage Notes for Exporting Data to a Flat File
Determine the location of the flat file for use in specifying the $FILE_WRITER FileName
attribute, which must be a complete pathname.
The $EXPORT operator is shown in this job example, however, you must use the SQL Selector
operator ($SELECTOR) to export:
•
TEXT or VARTEXT data
•
Large Objects (BLOB/CLOB data)
For information on the SQL Selector operator, see Teradata Parallel Transporter User Guide.
Creating an Export Job Script
1
Use Notepad or another text editor to create the job script, using the easy scripting format
and standard operator definitions ($EXPORT and $FILE_WRITER). For example:
DEFINE JOB job_name
(
APPLY $INSERT TO OPERATOR ($FILE_WRITER)
SELECT * FROM OPERATOR($EXPORT);
);
2
Save the file as job_name.txt to the directory set up for this and similar jobs, for example,
on Windows:
C:/Program Files/Teradata/Client/client_version/Teradata Parallel Transporter/Expt_Jobs
Teradata Data Warehouse Appliance 2690 Implementation Guide
275
Chapter 15: Moving Data To and From Teradata Database Tables
Exporting Data to an External Flat File
Defining the Local Job Variables
A TPT job that exports data from a Teradata Database table to an external flat file normally
requires definition of certain job variables.
1
Identify the $FILE_WRITER operator attributes you want to use and define values to the
corresponding job variable names. Commonly used $FILE_WRITER attributes are:
$File_Writer
Job Variable Name
Job Variable Value
TargetFileName
The fully qualified name of the flat file to which $FILE_WRITER writes
the data, for example, a Windows pathname.
TargetFormat
The format of the TargetFile, which can be any of the following values:
• 'Delimited' = in text format with each field separated by a delimiter
character. When you specify Delimited format, you can use the
optional TextDelimiter attribute to specify the delimiter character.
The default is the pipe character ( | ).
Note: The fields specified for this attribute must use the VARCHAR
data type. Non-VARCHAR specifications result in an error.
• 'Binary': A 2-byte integer, n, followed by n bytes of data.
• 'Formatted' = both prefixed by a record-length marker and followed
by an end-of-record marker.
• 'Text' = character data separated by an end-of-record (EOR) marker.
• 'Unformatted' = not formatted. The data has no record or field
delimiters and must be specified using a Teradata PT schema.
For details about using formats other than 'Delimited', see
“DataConnector Operator” in Teradata Parallel Transporter Reference.
SourceTextDelimiter
The delimiter used in the SourceFile, for example, '|' (the default) or ',' .
To use the tab character as a delimiter, use uppercase'TAB', not 'tab'.
Note: If a character used as a delimiter also appears as part of the data,
it must be preceded by a backslash character. For example, when a
comma delimited flat file includes an address field that allows commas,
the address must appear in the form: Los Angeles\, California
OpenMode
2
276
The access mode ('read' or 'write'). The value for $File_Writer is 'write'.
Identify the $EXPORT operator attributes you want to use and assign values to the
corresponding job variable names. Commonly used $EXPORT operator attributes are:
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Exporting Data to an External Flat File
Export Operator
Job Variable Name
Description
Values for these variables may have already been specified in the
global job variables file. If so, they only need to be respecified in
local job variables file if you want to change values.
SourceTdpId
SourceUserName
See “Setting Up the Global Job Variables File” on page 265 for
specification instructions.
SourceUserPassword
SourceAccountId
ExportPrivateLogName
The name of a file in the Logs directory to which the system
writes job information about the $EXPORT operator, for
example, ExportLog.
If no private log name is specified, the log is stored in the public
log.
SelectStmt
The SQL SELECT statement which identifies the Teradata
database, table, and columns that the $EXPORT operator should
read. For example:
SELECT * FROM databasename.tablename;
or if you are selecting a subset of available SourceTable columns:
SELECT
column_name1,
column_name2,
...
FROM databasename.tablename;
Note: TPT supports most Teradata SQL SELECT statement
options, including WHERE clauses, CASE statements, and
UNION ALL. See Teradata Parallel Transporter User Guide.
3
Use Notepad or other plain text editor to create the job variables file and set the attribute
values for the variables as described in step 1 and step 2, for example:
TargetFileName
,TargetFormat
,TargetTextDelimiter
,OpenMode
,SourceTdpId
,SourceUserName
,SourceUserPassword
,SourceAccountId
,ExportPrivateLogName
,SourceTable
,LogTable
,SelectStmt
4
=
=
=
=
=
=
=
=
=
=
=
=
'flatfile_name'
'delimited'
'|'
'write'
'tdpId'
'tdusername'
'tdpassword'
'account_id'
'exportlog'
'databasename.tablename'
'jobname_restart'
'SELECT * FROM databasename.tablename'
Save the job variables file as job_nameVar.txt to the directory that contains the job script.
Note: For information on running a job, see Launching a Teradata PT Job
Teradata Data Warehouse Appliance 2690 Implementation Guide
277
Chapter 15: Moving Data To and From Teradata Database Tables
Launching a Teradata PT Job
Launching a Teradata PT Job
Use the tbuild command to launch a Teradata PT job.
1
In a Command window, navigate to the directory where the job script is stored. For
example: C:/Program Files/Teradata/Client/14.00/Teradata Parallel Transporter/LoadJobs
2
Enter the following at the command prompt:
tbuild -f filename -v job_variables_filename
-j jobname
where:
Option or Parameter
Specifies
-f filename
The file name of the job script. The file name should use a .tpt
extension.
If you do not execute the tbuild command in the directory
where the job script is stored, filename must be a fully qualified
pathname.
-v
job_variables_filename
The job variables file associated with the job script. See
“Defining the Local Job Variables” on page 267.
If you are not executing the tbuild command in the directory
where the job script is stored, or if the job variables file is not
located in the same directory as the job script, job_variables_file
must be a fully qualified pathname.
-j jobname
A unique name that helps to easily identify the public log and
checkpoint log for a job.
Jobname must be the last argument in the tbuild command.
The screen will display an Exit Code when the job completes. For information on exit
codes, see “Examining the Exit Codes” on page 280.
Specifying Job Variables at Job Launch
You can specify job variables on the command line as part of the tbuild command that
launches a job, for example, to specify a different username and password. Command line
variable values supercede any corresponding variable values that may exist in the local and
global job variables files. For example:
tbuild -f filename -v jobvariable_filename -u “jobvariable_name =
‘value’[,jobvariable_name = ‘value’]” jobname
278
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Monitoring and Managing a Teradata PT Job
Reference Information
Information on...
Is available in...
tbuild syntax and options
Teradata Parallel Transporter Reference
using tbuild
Teradata Parallel Transporter User Guide
Monitoring and Managing a Teradata PT Job
Teradata PT provides the capability to monitor and manage a job while it is running.
•
•
The twbcmd command allows you to:
•
Pause and resume a job.
•
View the status of a job.
The twbkill command allows you to stop a job.
Pausing and Resuming a Job
After a Teradata PT job launches, you can pause and then resume the job using the twbcmd
command.
1
From the command line in the working directory, enter the following command to pause
the job:
twbcmd job_id JOB PAUSE
where job_id is the job name followed by a dash (“-”) and the job sequence number
generated by the system at launch.
2
When you are ready to continue, enter the following command to resume the job:
twbcmd job_id JOB RESUME
The job resumes at the point at which it was paused.
Reference Information
Information on...
Is available in...
twbcmd syntax and options
Teradata Parallel Transporter Reference
using twbcmd
Teradata Parallel Transporter User Guide
Viewing the Job Status
Do the following to check the status of a running job.
1
From the command line in the working directory, enter the following command to check
job status:
twbcmd job_id JOB STATUS
Teradata Data Warehouse Appliance 2690 Implementation Guide
279
Chapter 15: Moving Data To and From Teradata Database Tables
Evaluating a Completed Teradata PT Job
where job_id is the job name followed by a dash (“-”) and the job sequence number
generated by the system at launch.
Terminating a Job
If you need to terminate a running job, for example if continuation of the job could either
cause system failures or significantly impact overall system performance, you can use the
twbkill command to force all executing job tasks to terminate immediately.
1
From the command line in the working directory, enter the following command to
terminate a job:
twbkill job_id
where job_id is the job name followed by a dash (“-”) and the job sequence number
generated by the system at launch.
2
When the job terminates, check the logs, as shown in “Troubleshooting a Failed Job” on
page 281, to determine the cause of the job termination.
Reference Information
Information on...
Is available in...
the twbkill command
• “Managing an Active Job” in Teradata Parallel
Transporter User Guide
• “Teradata PT Utility Commands” in Teradata Parallel
Transporter Reference
Evaluating a Completed Teradata PT Job
Examining the Exit Codes
Upon completion, each Teradata PT job returns an exit code to indicate job success or failure.
1
Examine the job exit code, which appears on the screen where you launched the job.
Exit Code
Description.
0
Completed successfully.
4
Completed successfully, but issued one or more warnings.
8
Terminated due to a user error, such as a syntax error.
12
Terminated due to a fatal error.
A fatal error is any error other than a user error.
2
Determine whether or not further action is required.
•
280
If the exit code is 0, the job was successful and no further action is required.
Teradata Data Warehouse Appliance 2690 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Troubleshooting a Failed Job
3
•
If the exit code is 4, you can check the logs to examine the warning(s) and determine
whether or not you should revise the portion of the script that generated each warning
to avoid a possible future failure.
•
If the exit code is 8 or 12, revise the script to correct the error.
For jobs that return an exit code that requires examination of the job logs, go on to
“Troubleshooting a Failed Job” on page 281.
Reference Information
Information on...
Is available in...
exit codes, error tables, logs, and strategies
for evaluating a job
The chapter on “Post-Job Considerations” in Teradata
Parallel Transporter User Guide
Troubleshooting a Failed Job
To fix a failed TPT job, you must be able to detect the cause of the failure and correct it.
1
2
Access the logs and error tables for the job.
•
The Public Log is located in the Logs directory. See “About TPT Configuration Files”
on page 264.
•
Private (operator) logs and error tables are named and located as shown in Defining
the Local Job Variables for the job.
Evaluate the logs and any errors they contain.
•
If the job fails before it runs, the failure may have been caused by a tbuild error, a
scripting syntax error, or a system resource issue. The associated errors and warnings
are in the public log.
•
If the job runs but fails to complete, it may be due to an initialization error, such as an
invalid operator attribute specification, or a data acquisition error, such as an
improper SQL SELECT statement. These errors may be found in both the public log
and private logs.
•
If an error is detected in a private (operator) log, you also need to evaluate the
corresponding information in the error tables for the operator, which provide more
detailed information about the error.
For detailed information about detecting and correcting job errors, see the chapter on
“Troubleshooting a Failed Job” in Teradata Parallel Transporter User Guide.
3
Once the causes of errors have been corrected in the job script, you can re-launch the job.
Teradata Data Warehouse Appliance 2690 Implementation Guide
281
Chapter 15: Moving Data To and From Teradata Database Tables
Checkpoint
Checkpoint
Before leaving Chapter 15: “Moving Data To and From Teradata Database Tables,” make sure
that:
√
Result
Reference
The Global Job Variables file is set up and ready
for use.
“Setting Up the Global Job Variables
File” on page 265
You have created the required job script and
local job variables file, and have loaded at least
one Teradata Database table with data from an
external ODBC source table.
“Loading a Data From an External
ODBC Database” on page 266
You have created the required job script and
local job variables file, and have loaded at least
one Teradata Database table with data from an
external flat file.
“Loading Data from an External Flat
File” on page 271
You have created the required job script and
local job variables file, and have exported data
from at least one Teradata Database table to an
external flat file.
“Exporting Data to an External Flat
File” on page 275
You have successfully launched a TPT job and
monitored it as it ran.
“Launching a Teradata PT Job” on
page 278
You have used the TPT error code system to
evaluate a completed job.
“Evaluating a Completed Teradata PT
Job” on page 280
You understand how to examine the logs and
error files to determine the cause and corrective
action for a failed job.
“Troubleshooting a Failed Job” on
page 281
If you do not have these results, return to the section in the Reference column and review that
procedure.
282
Teradata Data Warehouse Appliance 2690 Implementation Guide
Type and Format Differences
Between Teradata and Other DBMS
APPENDIX A
This appendix describes the differences between the types and formats used in Teradata and
those used in other database management systems, for example, Oracle.
About Teradata Data Types
Teradata Database data types may differ from the data types in other ANSI-compliant
databases. You may need to convert some existing data types into Teradata data types.
Be aware that even though some data types seem the same in both systems, there may be
subtle differences in the way the data types are implemented. Queries using these data types
may not return an error, but the results may not be as expected.
Recommendation: Always test queries thoroughly after converting to Teradata data types and
make sure that the data type functions as you expect.
The following table shows how some Oracle data types can be mapped to Teradata data types:
Oracle Data Type
Teradata Data Type
BINARY_DOUBLE
FLOAT
BINARY_FLOAT
FLOAT
BLOB/CLOB
BLOB/CLOB
CHAR
CHAR
DATE
DATE or TIMESTAMP(0)
FLOAT
NUMBER
LONG
LONG VARCHAR or VARCHAR
LONG RAW
VARBYTE (<=64000)
NUMBER or NUMBER (*)
NUMBER or NUMBER (*)
NUMBER(38)
NUMBER(38)
NUMBER(n, m)
NUMBER(n, m)
VARCHAR2
VARCHAR
Teradata Data Warehouse Appliance 2690 Implementation Guide
283
Appendix A: Type and Format Differences Between Teradata and Other DBMS
About Teradata Data Types
In Teradata, the maximum number of characters or bytes allotted to a CHAR or VARCHAR
column depends on the character size of server character set for the column. For example, if
the server character set is:
•
LATIN (single-byte), then the maximum value is 64,000
•
UNICODE (double-byte), then the maximum value is 32,000
Teradata has several additional numeric data types, including:
•
BYTEINT - a signed binary integer value from -128 to 127
•
SMALLINT - a signed binary integer value from -32,768 to 32,767
•
INTEGER - a signed, binary integer value from -2,147,483,648 to 2,147,483,647
•
BIGINT - a signed, binary integer value from -9,223,372,036,854,775,808 to
9,223,372,036,854,775,807
Note: Oracle does not have an INTEGER data type, but it does have an alias called INTEGER
that maps to the NUMBER data type.
DATE Formats
In Teradata, the date format for the system is set with the DateForm configuration setting and
the default date format setting in the specification for data formatting (SDF) file.
Those settings determine the following:
•
Export data type of DATE values
•
Data entry format for DATE values
•
Format of DATE values in macros being executed
•
Date format for string-to-DATE comparisons and conversions
•
Display format of DATE columns in newly created tables and views
To view the current system default DATE format, enter:
HELP SESSION;
You can use the dbscontrol utility DateForm setting to reset the system-level date format.
DateForm Setting
Description
0 (IntegerDate, the
default)
Use the system default DATE format specified in the SDF file.
The default format is YY/MM/DD. However, you can customize the SDF
file to change this date format to any valid date format.
The export data type is four-byte integer.
1 (ANSIDate)
The system default DATE format is YYYY-MM-DD.
The export data type is CHARACTER(10).
This format is similar to the DATE data type format in Oracle.
For details about the DateForm setting, see DBS Control in Utilities: Volume 1 (A-K).
284
Teradata Data Warehouse Appliance 2690 Implementation Guide
Appendix A: Type and Format Differences Between Teradata and Other DBMS
About Teradata Data Types
You can also override the system-level date format.
To change the DATE format setting for ...
Use the ...
the system
• DBS Control utility to change the DateForm setting.
• Locale Definition utility (tdlocaledef) to customize
the SDF file.
the session
SET SESSION DATEFORM statement.
a user
DATEFORM option in the CREATE USER or
MODIFY USER statement.
a DATE column or DATE value
FORMAT phrase.
Recommendation: To avoid format errors in date operations, specify dates as ANSI DATE
literals. All SQL date operations accept this format. The format for an ANSI DATE literal is:
DATE 'YYYY-MM-DD'
Geospatial Types
Teradata Database supports geospatial types. Geospatial information identifies the geographic
location of features and boundaries on the planet. Geospatial types address the need to store,
manage, retrieve, manipulate, and analyze geospatial information by governmental bodies
and commercial enterprises. For example, local governments might use geospatial data for city
planning, traffic management, or accident investigation.
You can use geospatial types to represent 0-dimensional (point), 1-dimensional (line), and 2dimensional (polygon) geometries.
Teradata Database implements geospatial types as system-defined structured types. The
geospatial types define methods that perform geometric calculations and test for spatial
relationships between two geospatial values.
For more information, see SQL Geospatial Types.
User-Defined Types
Teradata Database supports user-defined types (UDTs). SQL provides a set of predefined data
types, such as INTEGER and VARCHAR, that you can use to store the data that your
application uses, but they might not satisfy all of the requirements you have to model your
data.
User-defined types allow you to extend SQL by creating your own data types and then using
them like predefined data types. You can also define methods that operate on the UDT.
Teradata Data Warehouse Appliance 2690 Implementation Guide
285
Appendix A: Type and Format Differences Between Teradata and Other DBMS
Reference Information
Distinct Types
Distinct UDTs are based on a single predefined data type, such as INTEGER or VARCHAR.
For example, you can create a distinct UDT named euro that is based on a DECIMAL(8,2)
data type and use it to store monetary data. You can define a method for the euro type that
converts the value to a US dollar amount.
Structured Types
Structured UDTs are collections of one or more fields called attributes, each of which is
defined as a predefined data type or other UDT (which allows nesting).
For example, you can create a structured UDT named circle that consists of x-coordinate,
y-coordinate, and radius attributes. You can define a method for the circle type that computes
the area of the circle using the radius attribute.
Note: Teradata has different storage definition requirements than Oracle and does not use
extents or table spaces.
Reference Information
Information on...
Is available in...
supported data types in Teradata Database,
including UDTs
SQL Data Types and Literals
DATE literals
SQL Data Types and Literals
DATE formats and the FORMAT phrase
286
using the DBS Control utility (dbscontrol)
to change the DateForm setting
Utilities: Volume 1 (A-K)
the SDF file and the Locale Definition
utility (tdlocaledef)
Utilities: Volume 2 (L-Z)
• CREATE USER / MODIFY USER
• HELP SESSION
• SET SESSION DATEFORM
SQL Data Definition Language Detailed Topics
Teradata Data Warehouse Appliance 2690 Implementation Guide
APPENDIX B
Loading and Updating Tables with
BTEQ
This appendix describes using BTEQ to load data into Teradata Database or to update existing
tables.
Differences Between BTEQ and Teradata PT
BTEQ and Teradata PT can both load data into Teradata and can update tables, among other
functions. Other similarities include:
•
Capacity: Both can send up to 64 KB per request and up to 1 MB per request with array
support.
•
Capabilities: Both can support multiple sessions and can load, export, process DDL, and
act as a command line interface.
The following table explains the major differences between BTEQ and Teradata PT:
BTEQ
Teradata PT
Consumes less client CPU.
Consumes more client CPU.
Loads or updates either all records or stops after x
records that you specify with the REPEAT command.
Can also load or update only selected rows.
Limited error handling.
Performs error handling and creates error
log tables.
No checkpoint restart.
Checkpoint restart.
No SERIALIZE option.
SERIALIZE option ensures the correct
sequencing of transactions.
Does not process multiple DML statements in a single
pass of the input data.
Can perform conditional apply or multiple
apply.
Recommendation: If your job has millions of rows, use Teradata PT. If not, especially for a
load job that will be used again in the future, consider both. See which performs better and
causes less system overhead. BTEQ can be a good choice for smaller amounts of data,
exploratory work, and DDL.
Teradata Data Warehouse Appliance 2690 Implementation Guide
287
Appendix B: Loading and Updating Tables with BTEQ
Loading Tables
Loading Tables
Use the following BTEQ input stream to load (import) data into the Teradata Database:
.IMPORT DATA FILE=DeptData.imp
.REPEAT *
USING
DeptNo (SMALLINT),
DeptName (VARCHAR(14)),
Loc (CHAR(3)),
MgrNo (SMALLINT)
INSERT INTO Personnel.newtable (DeptNo, DeptName,
Loc,MgrNo)
VALUES
(:DeptNo, :DeptName, :Loc, :MgrNo);
where:
•
The REPEAT * command repeats the next request until the data in the import file is
exhausted.
•
The term newtable refers to an empty table to receive the data being loaded.
Reference Information
Information on...
Is available in...
BTEQ commands, including
PACK
Basic Teradata Query Reference
running batch jobs to submit
BTEQ commands and
Teradata SQL
• “Using BTEQ Scripts to Create Database Objects” on page 123
• Basic Teradata Query Reference
Updating Tables
Frequently, when updating the Teradata Database, you make the same change to many rows. It
is helpful to eliminate the repetitive work required to update them individually. The REPEAT
command serves this purpose.
Updating Rows Using a Single Request
If you can describe all of the rows by some formula, then you can use a single request to
update them all. The following request, for example, updates the salaries of all employees in
department 600 of the database Personnel:
update personnel.employee set salary=salary*1.07
where deptno=600;
288
Teradata Data Warehouse Appliance 2690 Implementation Guide
Appendix B: Loading and Updating Tables with BTEQ
Updating Tables
Updating Rows Using Multiple Requests
If you cannot describe all of the rows by a formula, you must describe them individually. The
following requests, for example, update the salaries of two employees:
update personnel.employee set salary=salary*1.07
where empno = 10006;
update personnel.employee set salary=salary*1.07
where empno = 10013;
This approach is convenient for a few updates, but if there were hundreds, the script would
become very long. It would also be very inflexible; you would have to edit each entry to use the
script again for another list of employees.
Updating Rows by Importing a File
A better approach would be to create a separate file (for example, RAISEEMP) containing two
records in data format representing the employee numbers 10006 and 10013. Then use the
BTEQ IMPORT command with a REPEAT command to update the rows in the database.
Using the REPEAT Command When Importing a File
The REPEAT command appears before the request and specifies the total number of requests
to be submitted.
The following BTEQ script using the BTEQ REPEAT command opens the character-format
file RAISEEMP and repeats the update sequence twice:
.IMPORT data file=raiseemp
.REPEAT 2
using enumb (char(5))
update personnel.employee set salary=salary*1.07
where empno = :enumb;
For each employee, BTEQ reads a value from the RAISEEMP file for the variable called enumb
and carries out the UPDATE for the row whose EmpNo equals the value of enumb.
Caution:
When using a file originally exported with the BTEQ EXPORT command as the source for an
IMPORT command across a different platform type, ensure that the endianness type of both
platforms is the same. You can verify this from the “Client Platform Byte Order” tab in the
output of the SHOW CONTROLS command.
Teradata Data Warehouse Appliance 2690 Implementation Guide
289
Appendix B: Loading and Updating Tables with BTEQ
Updating Tables
290
Teradata Data Warehouse Appliance 2690 Implementation Guide
APPENDIX C
Advanced Features
This appendix describes advanced features that can benefit your system after it is set up and
functioning smoothly.
About Procedures and External Procedures
If you have one or more SQL statements that you use repeatedly, you may want to store the
statements in a procedure in Teradata Database, and then simply call the procedure from your
application whenever you want to execute the SQL statements.
In addition to SQL statements such as INSERT and SELECT, procedures can use various
control and condition handling statements such as REPEAT and LOOP. This allows
procedures to support more complex SQL than macros. You can also pass input arguments to
the procedure and have it return output arguments.
Applications that use procedures can perform better because of greatly reduced network
traffic between client and server, and are easier to maintain because business rules are
encapsulated and enforced on the server.
Note: Teradata uses the following terminology for procedures:
•
Stored procedures (SQL procedures): Procedures that are written using SQL statements.
•
External procedures: Procedures that are written using C, C++, or Java.
Instead of using procedures, you may want to use macros to execute simple, repetitive SQL.
See “Working with Macros” on page 149.
Differences Between Macros and Procedures
Macros and procedures provide similar benefits. The following table provides a comparison
between macros and procedures.
Macros
Procedures
Supports limited procedural logic
Supports sophisticated logic
Provides easy execution of simple, repetitive
SQL
Provides easy execution of complex logic
Can use EXPLAIN to see the execution plan of
the entire macro
Must use EXPLAIN on each SQL statement in
the procedure
Teradata Data Warehouse Appliance 2690 Implementation Guide
291
Appendix C: Advanced Features
About Procedures and External Procedures
Macros
Procedures
Can reduce network traffic in the client-server
environment (procedures reside and execute on
the server)
Provides exception handling features to handle
the runtime conditions generated by an
application
Reference Information
Information on...
Is available in...
overview of procedures
SQL Fundamentals
SQL procedures (procedures that are written
using SQL statements)
SQL Stored Procedures and Embedded SQL
external procedures (procedures that are
written using C, C++, or Java)
SQL External Routine Programming
syntax and options for:
• SQL Data Definition Language Syntax and
Examples
• SQL Data Definition Language Detailed Topics
• CREATE PROCEDURE / REPLACE
PROCEDURE (SQL Form, External Form)
• RENAME PROCEDURE
• DROP PROCEDURE
• recompiling an existing procedure using
ALTER PROCEDURE (SQL Form, External
Form)
executing procedures
292
SQL Data Manipulation Language
Teradata Data Warehouse Appliance 2690 Implementation Guide
Appendix C: Advanced Features
User-Defined Functions
User-Defined Functions
SQL provides a set of useful functions, but they might not satisfy all of the particular
requirements you have to process your data.
User-defined functions (UDFs) allow you to extend SQL by writing your own functions in the
C, C++, or Java programming language, installing them on the database, and then using them
like standard SQL functions.
You can also install UDF objects or packages from third-party vendors or browse the Teradata
Download Center for UDFs that you might find useful. You can access the Teradata Download
Center from the Support & Downloads link at http://www.teradata.com.
Teradata Database supports three types of UDFs:
UDF Type
Description
Scalar
Scalar functions take input parameters and return a single value result. Examples of
standard SQL scalar functions are CHARACTER_LENGTH, POSITION, and TRIM.
Aggregate
Aggregate functions produce summary results. They differ from scalar functions in
that they take grouped sets of relational data, make a pass over each group, and return
one result for the group. Some examples of standard SQL aggregate functions are AVG,
SUM, MAX, and MIN.
Table
A table function is invoked in the FROM clause of a SELECT statement and returns a
table to the statement.
Reference Information
Information on...
Is available in...
implementing and using UDFs
SQL External Routine Programming
syntax and options for:
• SQL Data Definition Language Syntax and Examples
• SQL Data Definition Language Detailed Topics
•
•
•
•
•
CREATE/REPLACE FUNCTION
CREATE FUNCTION (Table Form)
ALTER FUNCTION
RENAME FUNCTION
DROP FUNCTION
invoking a table function in the FROM
clause of a SELECT statement
Teradata Data Warehouse Appliance 2690 Implementation Guide
SQL Data Manipulation Language
293
Appendix C: Advanced Features
Triggers
Triggers
If your application requires certain actions to take place when an INSERT, UPDATE, DELETE,
or MERGE SQL statement modifies a specific table, you can create a trigger and associate it
with the table. Triggers consist of a stored SQL statement or a block of SQL statements.
Triggers are particularly useful for audits of all kinds. For example, you might want a trigger to
insert a log record whenever an employee gets a salary raise larger than ten percent. Or you
might want to log activity every time a visitor to your website accesses a particular page to
make it easier and faster to produce a monthly report.
Reference Information
294
Information on...
Is available in...
triggers
• Introduction to Teradata
• SQL Fundamentals
Teradata Data Warehouse Appliance 2690 Implementation Guide
">