Teradata 2700 Data Warehouse Appliance Implementation Guide
Pubblicità
Pubblicità
Teradata Data Warehouse Appliance 2700
Implementation Guide
Release 14.0 SLES 11
B035-1196-063K
August 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.
T
HE 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
. S
OME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES
,
SO THE ABOVE EXCLUSION
MAY NOT APPLY TO YOU
. I
N NO EVENT WILL
T
ERADATA
C
ORPORATION 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
Audience
This guide describes the minimum tasks required to implement database operations on the
Teradata Data Warehouse Appliance 2700, 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.
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 in a SLES 11 environment on a Teradata
Data Warehouse Appliance 2700 and Teradata clients running Teradata Tools and Utilities
14.10.
Teradata Data Warehouse Appliance 2700 3
4
Preface
Changes to This Guide
Changes to This Guide
This guide includes the following changes to support the current release:
Release
Teradata Database 14.0 on
SLES 11
August 2013
Description
Initial release
Additional Information
URL
www.info.teradata.com/ www.teradata.com
www.teradata.com/t/TEN/ https://tays.teradata.com
developer.teradata.com/
Description
Use the Teradata Information Products Publishing Library site to:
•
View or download a manual:
1
2
Under Online Publications, select General Search.
Enter your search criteria and click Search.
•
Download a documentation CD-ROM:
1
2
Under Online Publications, select General Search.
In the Title or Keyword field, enter CD-ROM, and click Search.
•
Order printed manuals:
Under Print & CD Publications, select How to Order.
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
Teradata Customer Education designs, develops and delivers education that builds skills and capabilities for our customers, enabling them to maximize their Teradata investment.
Use Teradata @ Your Service to access Orange Books, technical alerts, and knowledge repositories, view and join forums, and download software patches.
Teradata Developer Exchange provides articles on using
Teradata products, technical discussion forums, and code downloads.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Preface
References to Linux and Windows
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 2700 runs on SUSE Linux Enterprise Server 11,
Service Pack 1, 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 2700 Implementation Guide 5
Preface
References to Linux and Windows
6 Teradata Data Warehouse Appliance 2700 Implementation Guide
Table of Contents
Preface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Chapter 1: Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 2: System Components
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Teradata Data Warehouse Appliance 2700 Cabinet Configurations . . . . . . . . . . . . . . . . 22
Chapter 3: Setting Up System Management
. . . . . . . . . . . . . . . . . . . 45
Setting Up an Internet Explorer Browser on a Windows Workstation . . . . . . . . . . . . . . 47
Teradata Data Warehouse Appliance 2700 Implementation Guide 7
Table of Contents
8
Navigating to the SMWeb Home Page from the SOV CMIC . . . . . . . . . . . . . . . . . . . . . . .48
Navigating to the SMWeb Home Page from a Non-SOV CMIC . . . . . . . . . . . . . . . . . . . .49
Chapter 4: Setting Up Teradata Clients
. . . . . . . . . . . . . . . . . . . . . . . . . . .71
Installing Third-Party Software for Teradata Parallel Transporter Base . . . . . . . . . . . . . .74
Installing Third Party Software for Teradata Parallel Transporter Wizard . . . . . . . . . . . .74
Installing Third-Party Software for Teradata WebSphere MQ Access Module . . . . . . . . .74
Teradata Data Warehouse Appliance 2700 Implementation Guide
Table of Contents
Chapter 5: Setting up Administrative Users
. . . . . . . . . . . . . . . . . . . . 85
Setting Up Database Administrator Access to Teradata Viewpoint . . . . . . . . . . . . . . . . 102
Chapter 6: Creating the Database Structure
. . . . . . . . . . . . . . . . . . 105
Teradata Data Warehouse Appliance 2700 Implementation Guide 9
Table of Contents
Chapter 7: Converting Queries to Teradata SQL
. . . . . . . . . . . . . . .131
10 Teradata Data Warehouse Appliance 2700 Implementation Guide
Table of Contents
Chapter 8: Querying the Database
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapter 9: Optimizing Query Performance
. . . . . . . . . . . . . . . . . . . . . 165
Using COLLECT STATISTICS to Optimize Query Performance . . . . . . . . . . . . . . . . . . . . . 165
Teradata Data Warehouse Appliance 2700 Implementation Guide 11
Table of Contents
12
Chapter 10: Setting Up Users
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Chapter 11: Monitoring Database Access
. . . . . . . . . . . . . . . . . . . . . . . .203
Teradata Data Warehouse Appliance 2700 Implementation Guide
Table of Contents
Chapter 12: Monitoring the Database
. . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Chapter 13: Managing the Database
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Teradata Data Warehouse Appliance 2700 Implementation Guide 13
Table of Contents
14
About Blocks and Delays Due to Workload Management Priorities . . . . . . . . . . . . . . . .235
Teradata Data Warehouse Appliance 2700 Implementation Guide
Table of Contents
Overriding Workload Management Effects for Queries and Sessions . . . . . . . . . . . . . . 257
Chapter 14: Maintaining the Database
. . . . . . . . . . . . . . . . . . . . . . . . . . 259
Chapter 15: Moving Data To and From
Teradata Database Tables
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Teradata Data Warehouse Appliance 2700 Implementation Guide 15
Table of Contents
16
Usage Considerations When Importing Data From an ODBC Database. . . . . . . . . . . . .296
Appendix A: Type and Format Differences Between
Teradata and Other DBMS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
Appendix B: Loading and Updating Tables with BTEQ
. . . . . . . .313
Updating Rows Using Multiple Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Updating Rows by Importing a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Teradata Data Warehouse Appliance 2700 Implementation Guide
Table of Contents
Using the REPEAT Command When Importing a File . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Appendix C: Advanced Features
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Teradata Data Warehouse Appliance 2700 Implementation Guide 17
Table of Contents
18 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 1
Introduction
This guide documents standard best practices for implementing a Teradata Data Warehouse
Appliance 2700 system. Actual implementations may vary according to individual site requirements.
Assumptions
The implementation procedures shown in this guide are based on the following assumptions:
•
The site has not previously used Teradata Database software.
•
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 2700 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 using the 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 provides basic instructions for Teradata Data Warehouse
Appliance 2700 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 3 through 13 in the order shown, unless otherwise directed in the text.
Teradata Data Warehouse Appliance 2700 Implementation Guide 19
Chapter 1: Introduction
Database Implementation Process
Database Implementation Process
System Configuration
Chapter 2
System Components
•
Hardware configuration
•
Software components
•
Configure system monitoring
•
Fix problems and open incidents
•
Install/configure client software
•
Connect clients to the database
Database Configuration
Setting up Administrative Users
•
Allocate system disk space
•
Create /provision administrators
Database Administration
•
Log user access attempts
•
Monitor access logs to detect issues
Creating the Database Structure
•
Create tiered database architecture
•
Design effective indexing
•
Set up Viewpoint users
•
Set up dashboards and alerts
Converting Queries to Teradata SQL
•
Convert data types/tables/joins
•
Convert SQL functions and other database operations
•
Create and submit queries
•
Understand and work with locks
•
Collect and analyze statistics
•
Analyze the EXPLAIN
•
Use secondary and join indexes
•
Create users, roles, and profiles
•
Assign user privileges
•
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
•
Create the Configuration files
•
Create load and export job scripts
•
Launch and manage a job
•
Evaluate and troubleshoot a job
20 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 2
System Components
This section presents an overview of the Teradata Data Warehouse Appliance 2700 system.
Hardware Components
This section provides hardware component information for the Teradata Data Warehouse
Appliance 2700 platform, in which:
•
Internal system communication uses BYNET-over-Ethernet or BYNET V5 protocol
•
The system can grow up to 22 nodes with BYNET-over-Ethernet or up to 324 nodes with
BYNET V5
Hardware components are housed in Teradata platform cabinets. Every platform cabinet contains the following hardware:
•
A maximum of two cliques. Each clique consists of two or four processing (Teradata
Database) nodes:
•
A 2-node clique consists of:
•
Two processing nodes
•
Two disk arrays (with 72 storage drives)
•
A 4-node clique consists of:
•
Four processing nodes
•
Three disk arrays (with 144 storage drives)
•
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 or two BYNET V5 switches
•
Two 1-Gigabit Ethernet server management switches
•
Power hardware
•
One keyboard/video/mouse (KVM) unit in processing/storage cabinet 1
•
Up to eight Teradata managed servers (BAR, Viewpoint, SAS, etc.), channel servers, or extended channel solution (ECS) servers may be in 1 base processing/storage cabinet
For component information, see “Cabinet Component Descriptions” on page 29
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 21
Chapter 2: System Components
Hardware Components
Teradata Data Warehouse Appliance 2700 Cabinet Configurations
The following cabinet diagrams show example component arrangements. Actual deployed cabinets may contain fewer components than shown, depending on system configuration.
Figure 1: Base Cabinet Builds
24
23
22
2-Node Clique
2 Nodes, 2 Disk Arrays (72 Drives)
8 TMS/Channel/ECS Servers
Secondary SM Enet Switch
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
21
20
19
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
18
17
16
TMS / ECS / Channel
TMS / ECS / Channel
15
13
12
11
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
10
9
Node
Node 8
7
6
5
4
3
2
1
#
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Primary SM Enet Switch managed chassis
# unmanaged chassis
4-Node Clique
4 Nodes, 3 Disk Arrays (144 Drives)
8 TMS/Channel/ECS Servers
Secondary SM Enet Switch
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
Node
4-Node + 2-Node Cliques
6 Nodes, 5 Disk Arrays (216 Drives)
2 TMS/Channel/ECS Servers
Secondary SM Enet Switch
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
TMS / ECS / Channel
TMS / ECS / Channel
Node
Node
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch components loaded/accessible from rear of cabinet
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
Cabinet_0350
22 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Figure 2: Expansion Cabinet Builds
22
21
20
19
18
17
16
24
23
4-Node + 2-Node Cliques
6 Nodes, 5 Disk Arrays (216 Drives)
Secondary SM Enet Switch
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
15
13
12
11
Node
Node
Cabinet VMS
Node
Node
10
9
8
7
6
5
4
3
2
1
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
# managed chassis
# unmanaged chassis
4-Node + 4-Node Clique
8 Nodes, 6 Disk Arrays (288 Drives)
Secondary SM Enet Switch
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Node
Node
Node
Node
Cabinet VMS
Node
Node
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch components loaded/accessible from rear of cabinet
Cabinet_0352
Teradata Data Warehouse Appliance 2700 Implementation Guide 23
Chapter 2: System Components
Hardware Components
Figure 3: Base Cabinet Builds for Test/Development Systems
24
23
22
21
20
2-Node Clique
2 TMS/Channel/ECS Servers
2 Test/Dev Systems
Secondary SM Enet Switch
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
19
18
17
TMS / ECS / Channel
TMS / ECS / Channel
Test/Dev Node
4-Node Clique
2 TMS/Channel/ECS Servers
2 Test/Dev Systems
Secondary SM Enet Switch
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
TMS / ECS / Channel
TMS / ECS / Channel
Test/Dev Node
4-Node Clique
5 TMS/Channel/ECS Servers
1 Test/Dev System
Secondary SM Enet Switch
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
TMS / ECS / Channel
16 Test/Dev Node Test/Dev Node Test/Dev Node
15
13
12
11
10
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
9
Node Node Node
8
7
6
Node
4
5
3
2
1
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Primary SM Enet Switch
# managed chassis
# unmanaged chassis
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch components loaded/accessible from rear of cabinet
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
Cabinet_0351
24 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Figure 4: Base Cabinet Builds with 2-Node Cliques and Quantum Scalar i80 Tape Libraries
24
2-Node Clique
1 i80 Tape Library, 1 TMS BAR Server
Secondary SM Enet Switch
24
2-Node Clique
1 i80 Tape Library, 1 BAR Switch,
2 SKM Servers, 1 TMS BAR Server
Secondary SM Enet Switch
20 i80 Tape Library
8
7
10
9
6
5
4
3
2
1
16
15
13
12
11
TMS BAR
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
20 i80 Tape Library
8
7
10
9
6
5
4
3
2
1
19
18
17
16
15
13
12
11
Dell 2824 Switch
Scalar Key Manager Server 1
Scalar Key Manager Server 1
TMS BAR
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
# managed chassis
# unmanaged chassis components loaded/ accessible from rear of cabinet
Cabinet_0430
Teradata Data Warehouse Appliance 2700 Implementation Guide 25
Chapter 2: System Components
Hardware Components
Figure 5: Base Cabinet Builds with 4-Node Cliques and Quantum Scalar i80 Tape Libraries
24
4-Node Clique
1 i80 Tape Library, 1 TMS BAR Server
Secondary SM Enet Switch 24
4-Node Clique
1 i80 Tape Library, 1 TMS BAR Server
2 Key Mgmt Servers
Secondary SM Enet Switch 24
4-Node Clique
2 i80 Tape Libraries, 1 TMS BAR Server
Secondary SM Enet Switch
20 i80 Tape Library
20 i80 Tape Library
20 i80 Tape Library
19
18
19
18
Dell 2824 Switch
Scalar Key Manager Server
17 i80 Tape Library
2
1
4
3
10
9
17
16
15
13
12
11
8
7
6
5
TMS BAR
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
# managed chassis
17
16
15
13
12
11
10
9
8
7
6
5
4
3
2
1
# unmanaged chassis
Scalar Key Manager Server
TMS BAR
16
TMS BAR
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
15
13
12
11
Node
BYNET-1 Switch cabling slot
BYNET-0 Switch
System VMS
KVM
Node
10
9
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
8
7
6
5
4
3
2
1
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch components loaded/accessible from rear of cabinet
Cabinet_0431
26 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Figure 6: High-Density CPU Cabinet Builds
Configuration Option 1:
2 48-port 1Gb Ethernet switches
(chassis #1 and #24) in 2700 cabinet shared by server management and BYNET networks
PLUS KVM in external cabinet
24
23
22
21
20
19
18
High-Density CPU Cabinet with 2 Cliques
8 Nodes, 6 Disk Arrays (288 Drives)
48-Port or 24-Port Enet Switch
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
17
Node
16
Node
15
Node
13
12
11
Node
Cabinet VMS
Node
Node
Configuration Option 2:
2 24-port 1Gb Ethernet switches
(chassis #1 and #24) in 2700 cabinet for server management network
PLUS 2 36-port InfiniBand switches for BYNET network and KVM in Platform Framework Cabinet
10
9
5
4
3
2
1
8
7
6
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
48-Port or 24-Port Enet Switch
# managed chassis
# unmanaged chassis components loaded/accessible from rear of cabinet
Cabinet_0396
Teradata Data Warehouse Appliance 2700 Implementation Guide 27
Chapter 2: System Components
Hardware Components
Figure 7: Half-Cabinet Builds
24
23
One Clique Base Cabinet
Half Cabinet
One 2+0 Clique
24-Port Secondary Enet Switch
MUST BE EMPTY
22
MUST BE EMPTY
21
MUST BE EMPTY
20
MUST BE EMPTY
19
18
MUST BE EMPTY
MUST BE EMPTY
17
MUST BE EMPTY
16
15
13
12
11
10
9
8
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
KVM
System VMS
BYNET-1 Switch cabling slot
BYNET-0 Switch
Node
Node
7
4
3
2
1
6
5
TMS (opt)
TMS (opt)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
Drive Enclosure
(ESM, 18 drives)
Drive Enclosure
(Controller, 18 drives)
24-Port Primary Enet Switch
One Clique Expansion Cabinet
Half Cabinet
One 4+0 Clique
Secondary SM Enet Switch
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
MUST BE EMPTY
Cabinet VMS
Node
Node
Node
Node
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Drive Enclosure
(ESM, 24 drives)
Drive Enclosure
(Controller, 24 drives)
Primary SM Enet Switch
4
3
2
1
6
5
8
7
10
9
15
13
12
11
19
18
17
16
24
23
22
21
20
# managed chassis
# unmanaged chassis components loaded/accessible from rear of ca
Cabinet_0536
28 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Cabinet Component Descriptions
The following table describes the Teradata Data Warehouse Appliance 2700 components shown in “Example Cabinet Configurations.”
Component
Processing Node
Operating System
Teradata Database
Description
Each Teradata Data Warehouse Appliance 2700 base cabinet contains two to six database nodes; each expansion cabinet contains two to eight database nodes. Nodes consist of an
Intel R2208 chassis with:
•
Two 2.6 GHz eight-core ES-2670 processors (20MB 1.3 cache)
•
128 GB or 256 GB memory using 16 GB DIMMs (1333 MHz DDR3)
•
Disk drives:
•
Two 600 GB SAS (serial attached SCSI) drives for OS
•
One 600 GB SAS drive for dump processing to improve restart performance
•
Five additional drive bays available for customer use; 600 GB drives supported
•
DVD drive
•
Onboard connectivity to the server management network
•
Onboard connectivity to the BYNET-over-Ethernet network or adapter connectivity to the BYNET InfiniBand network
•
Disk storage adapters
•
Compression engine adapters
•
Optional network communication adapter
•
Optional network connection to managed BAR servers
•
Optional quad-port 1 GbE or dual-port 10 GbE modules for additional network communication
•
SUSE Linux Enterprise Server 10 (SLES 10) SP3
•
SUSE Linux Enterprise Server 11 (SLES 11)
Caution: Contact your Teradata representative to confirm the exact version of the Teradata
Database and PDE packages required for this platform.
For SUSE Linux Enterprise Server 10 (SLES 10):
•
Teradata Database Release 13.10.04.12 or later
•
Teradata Database Release 14.00.01.05 or later
For SUSE Linux Enterprise Server 11 (SLES 11):
•
Teradata Database Release 14.00.02.02 or later
Teradata Data Warehouse Appliance 2700 Implementation Guide 29
Chapter 2: System Components
Hardware Components
Component
Disk Storage
Channel Server
Extended Channel Solution
(ECS) Server
Teradata Managed Server
(TMS)
Description
Each Teradata Data Warehouse Appliance 2700 base cabinet contains two to five disk arrays, each expansion cabinet contains two to six arrays. A disk array is made up of two 5350
Camden drive enclosures. Each drive enclosure consists of:
•
Dual controller modules (in the lower enclosure of each disk array) or dual ESMs (in the upper enclosure)
•
Two power supply/cooling modules
•
SAS 2.5” 10K rpm drives available in 300GB, 600GB, and 900GB capacities
The number of disk arrays and drives vary according to system and clique configuration:
•
Production system, 4-node clique: four database nodes connect to three disk arrays; 24 drives are used in each enclosure for 144 drives in the clique
•
Production system, 2-node clique: two database nodes connect to two disk arrays; 18 drives are used in each enclosure for 72 drives in the clique
•
Test/development system: one database node connects to one disk array; 18 drives are used in each enclosure for 36 total drives
Intel R2208 server, configured as dedicated server for interface between Teradata Database and IBM (or compatible) mainframe:
•
Dual 2.0GHz six-core 15MB L3 cache E5-2620 processors
•
128 GB memory in 16 GB DIMMs
•
Host channel adapters -- maximum three FICON and/or ESCON adapters (can mix types in same node)
•
No disk array support
•
Onboard connectivity to the server management network
•
Onboard connectivity to the BYNET-over-Ethernet network or adapter connectivity to the BYNET InfiniBand network, no AMPs assigned
•
Optional network communication adapter
For information about HCA configuration, see the Host Channel Adapter Installation and
Service Guide.
Dell R710 server, 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
•
Ethernet adapter connection to the processing nodes
•
Optional network communication adapter
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.
30 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Component
Dump Server
BAR Hardware
BYNET-over-Ethernet
Interconnect
BYNET V5 Interconnect
Description
Dell R720xd server, configured as dedicated hardware to be used for crash dump data analysis.
Data can be offloaded from the production data warehouse environment to a dump server, allowing for analysis without disruption to the production system. The dump server must run the same version of Teradata Database as the production system from which the dump data was offloaded.
Each dump server consists of:
•
Two 2.6 GHz eight-core 20MB L3 cache E5-2670 processors, dual socket
•
256 GB memory in 16 GB DIMMs (1333 MHz DDR3)
•
Two 2.5" 10K rpm 900GB SAS drives for OS
•
Twenty-four 2.5" 10K rpm 900GB SAS drives for storage
•
Onboard connectivity to the server management network
Note: One portable USB DVD ROM drive is included per system that uses a Dell R720xd dump server. The product ID number for the USB DVD ROM drive kit is 2021-K944-V001.
The kit includes instructions for using the drive.
Quantum Scalar i80 tape library for automated retrieval, storage, and management of backup tape cartridges. The i80 is available in the base processing/storage cabinet.
A Quantum Scalar key manager is also available in the base processing/storage cabinet.
Redundant BYNET-over-Ethernet switches for processing node (TPA) and channel server communication available in processing/storage cabinets:
•
24-port Ethernet switch chassis for systems with a maximum 22 TPA nodes and channel servers in any combination
Redundant BYNET V5 switches using BYNET-over-InfiniBand for processing node (TPA) and channel server communication available in processing/storage cabinets or BYNET V5 cabinets.
•
In processing/storage cabinets:
•
36-port InfiniBand switch chassis for systems with a maximum 36 TPA nodes and channel servers in any combination
•
In BYNET V5 cabinets:
•
162-port InfiniBand switch chassis for systems with a maximum 162 TPA nodes and channel servers in any combination
Note: Some BYNET V5 cabinet configurations may also have TMSs, Cabinet VMSs, or
System VMSs. If a System VMS is included, a KVM is also included.
Teradata Data Warehouse Appliance 2700 Implementation Guide 31
Chapter 2: System Components
Hardware Components
Component
Adapters
Description
SAS disk storage adapter:
•
LSI 9200-16E quad 6 Gb SAS PCIe adapter in processing nodes and TMSs
Data reduction adapter:
•
Exar DX1845 PCIe2 adapter in processing nodes
BYNET Infiniband adapter (for BYNET V5 network):
•
Mellanox MCX354A-FCBT dual-port InfiniBand in processing nodes and channel servers
BYNET V4 adapter (for coresidence with 2690 systems using BYNET V4 network):
•
BIC2SE PCIe adapter in processing nodes and channel servers
Communications adapters:
•
Intel PRO/1000 PF dual PCIe adapter in processing nodes or TMSs
•
Intel PRO/1000 PT quad PCIe adapter in processing nodes or TMSs
•
Intel X520-DA2 dual-port 10 Gb copper adapter in processing nodes or TMSs
•
Intel X520-SR2 dual-port 10 Gb optical adapter in processing nodes or TMSs
Host channel adapters:
•
BTI ESCON PESA4 PCIe adapter
•
BTI FICON PEFA PCIe adapter
TMS BAR adapter:
•
QLogic QLE2564 quad port 8 Gb fibre channel to PCI adapter
32 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Component
Virtualized Management
Server (VMS)
Description
A virtualized management server (VMS) is an Intel R1208 chassis. A VMS 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.
An Intel R1208 VMS is available in Small System VMS, System VMS, and Cabinet VMS configurations. A Teradata Data Warehouse Appliance 2700 cabinet can contain a Small
System VMS, System VMS, or Cabinet VMS. A BYNET V5 cabinet can contain a System or
Cabinet VMS.
Small System VMSs support systems up to a maximum of 16 nodes and servers, and cannot be used in multi-system/multi-site ID configurations. Each Small System VMS consists of:
•
CMIC, SWS, and Viewpoint VMs
•
One 2.0 GHz six-core 15MB L3 cache E5-2620 processor, dual socket
•
32 GB memory using 8 GB DIMMs
•
Two 600 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
•
OS:
•
Linux SLES 11 OS on VMS and CMIC VM
•
Linux SLES 10 SP3 OS on SWS and Viewpoint VMs
Each System VMS consists of:
•
CMIC, SWS, and Viewpoint VMs. A Viewpoint VM supports up to a maximum of 128 nodes and servers
•
Two 2.0 GHz six-core 15MB L3 cache E5-2620 processors, dual socket
•
64 GB memory using 8 GB DIMMs
•
Two 600 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
•
OS:
•
Linux SLES 11 OS on VMS and CMIC VM
•
Linux SLES 10 SP3 OS on SWS and Viewpoint VMs
Each Cabinet VMS consists of:
•
CMIC VM
•
One 2.0 GHz six-core 15MB L3 cache E5-2620 processor, dual socket
•
32 GB memory using 8 GB DIMMs
•
Two 600 GB RAID 1 drives for boot/system operations
•
Onboard connectivity to server management network
•
Onboard or adapter connectivity to customer network
•
Linux SLES 11 OS on VMS and CMIC VM
Teradata Data Warehouse Appliance 2700 Implementation Guide 33
Chapter 2: System Components
Hardware Components
Component
Server Management Web
(SMWeb) Services
Multi-System/Multi-Site ID
Support
Enterprise Service
Workstation (SWS)
Description
Server management functions run on the CMIC VM (on a VMS). One CMIC VM is designated as the single operational view (SOV) CMIC. The SOV CMIC hosts the SMWeb
Services Home page and provides applications and services for server management on an
MPP system:
•
Server Management Client: Monitor status, display events, and perform commands from a single operational view of the system
•
Command Line Interface: Download remote command line interface utilities
•
Save and Restore: Download, upload, and view configuration files
•
Users and Groups: Manage user and group security levels
•
Network, Devices, and CMICs: Configure the server management network and device management
•
TVI Connection: Configure settings for TVI data communications to Teradata via the
Service Workstation
For use by customer on-site staff members, Teradata Services Analysts in the Global
Support Center (GSC), and Teradata Customer Service Representatives.
Note: SMWeb 10.02 and Teradata ServiceConnect are required for Teradata Data
Warehouse Appliance 2700 systems.
For information about using SMWeb Services, see the Teradata Server Management Web
Services User Guide, or the online help on the SMWeb Services home page.
The server management network (domain) can support up to three systems (or site IDs).
This functionality enables the inclusion of two test/development systems in the 2700 base cabinet, resulting in a system configuration that consists of one full production 2700 system and two single node-dual drive enclosure test/development systems.
Teradata Dell R710 workstation dedicated to system servicing and maintenance. Systems with an R1208 System VMS and more than 128 disk arrays, require dedicated Enterprise
SWS hardware (rather than a VMS with an SWS virtual machine). For systems that use dedicated Enterprise SWS hardware, the SWS hardware resides in a PFC cabinet.
•
Adapter connection to server management network
•
SLES 10 SP3 operating system
Note: The level of service depends on the service agreement between Teradata and the customer.
Enterprise Viewpoint Server Teradata Dell R710 server that hosts the Viewpoint portal that contains portlets for customer management of the Teradata Database. Systems that support multi-site IDs or systems that have more than 128 nodes require dedicated Enterprise Viewpoint hardware
(rather than a VMS with a Viewpoint virtual machine). For systems that use dedicated
Enterprise Viewpoint hardware, the Viewpoint hardware can reside in a PFC cabinet.
•
Adapter connection to server management network
•
SLES 10 SP3 operating system
Keyboard, Video, Mouse
(KVM) Console
The KVM resides in the first processing/storage cabinet and has VGA and USB connections to the VMS.
34 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Component
Cable Management
AC Power Subsystem
Hardware Compression
Coresidence
Description
Processing/storage cabinets are pre-wired for two cliques, with cable harness provided for server management Ethernet per node.
BYNET V5 cabinets do not have cable harnesses.
Platform Framework Cabinets have cable harnesses for power and server management.
Openings in cabinet sides near the rear of the rack accommodate inter-rack cabling.
Teradata Data Warehouse Appliance 2700 processing/storage cabinets:
•
Four PDUs, two on each inside rear panel of the cabinet.
•
Two or four AC feeder boxes inside the cabinet. Available AC feeder box types:
•
Three-phase Delta AC feeder box with a plug rated at 30A. Each cabinet has four AC feeder boxes; each AC feeder box has one power cord for a total of four power cords per cabinet.
•
Three-phase Delta AC feeder box with a plug rated at 60A. Each cabinet has two AC feeder boxes; each AC feeder box has one power cord for a total of two power cords per cabinet.
•
Three-phase Wye 230V L-N AC feeder box with a plug rated at 30A for North
America or 32A for Europe. Each cabinet has two AC feeder boxes; each AC feeder box has one power cord for a total of two power cords per cabinet. For use in North
America, this AC feeder box requires a specialized data center with power wired like a data center in Europe.
BYNET V5 cabinet:
•
Two AC boxes of the same type per cabinet.
•
For cabinets with the 162 port switch, the AC box type is a single-cord AC box with a plug rated at 30A (phase-phase) for North America and a plug rated at 32A (single- phase) for Europe. Each cabinet has two AC boxes; each AC box has one power cord for a total of two power cords per cabinet.
The PFC cabinet has two AC boxes of the same type per cabinet. For information about the
PFC cabinet power subsystem, see the Teradata Platform Framework Cabinet Product and
Site Preparation Guide.
The Teradata Data Warehouse Appliance 2700 platform uses hardware performance acceleration. The platform uses compression engine adapters in conjunction with the
Teradata Database block-level compression feature. The compression engines implement block-level compression without using the costly CPU overhead of software block-level compression. Compression design provides performance enhancement, for most workloads, and increased user capacity. Default block-level compression settings are preconfigured and optimized for 2700 system-level performance.
The Teradata Data Warehouse Appliance 2700 platform can coreside with the 2690 platform. When creating a coresident system, follow these guidelines:
•
Ensure that the same operating system and service pack level is installed on all processing nodes.
•
Ensure that the same Teradata Database version (including all the latest certified software/firmware levels) is installed on all processing nodes.
•
Apply the system configuration settings from the older platform to the newer platform.
•
For coresidence with 2690 platforms using BYNET V4, a BYNET V4 interface adapter must be installed in each processing node and channel server in the 2700 cabinet.
Teradata Data Warehouse Appliance 2700 Implementation Guide 35
Chapter 2: System Components
Hardware Components
Component
Full Disk Encryption
Description
The Teradata Data Warehouse Appliance 2700 platform supports full disk encryption for all database node disks, storage disks, and server disks in all system cabinets.
System Scalability
The scalability of Teradata Data Warehouse Appliance 2700 system is dependent on the
BYNET network configuration of the system:
•
A system using Dell 5524 1Gb Ethernet switches in the first processing/storage cabinet for
BYNET-over-Ethernet network can scale to 22 nodes.
•
A system using BYNET V5 cabinets for BYNET V5 network can scale to 324 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...
system cabinet configurations
Is available in...
“Teradata Data Warehouse Appliance 2700
Cabinet Configurations” on page 22 .
Customer Network and Mainframe Connection
Teradata Data Warehouse Appliance 2700 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 2700 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 2700 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
Information on...
network or channel attachments
Is available in...
“Communication Between the Client and Teradata
Database,” in Introduction to Teradata
36 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Hardware Components
Hardware Data Protection
Teradata Data Warehouse Appliance 2700 uses RAID1 technology to protect against disk failure and cliques to protect against node failure.
RAID1 Technology
Teradata Data Warehouse Appliance 2700 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 2700 nodes and disk arrays are interconnected into a clique configuration for fault tolerance. The following cliques are node to disk array interconnect. All links are point to point.
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.
Figure 8: Node to Disk Array Interconnect: 4-Node Production Clique
2 Quad 6Gbx4 SAS HBAs
0-3
Node 1 Node 2
2 1 2 1
Node 3 Node 4
2 1 2 1
1 2 3 4 1 2 3 4
A B
E E
1 2 3 4 1 2 3 4
A B
E E
1 2 3 4 1 2 3 4
A B
E E
Tray 0
24 HDD
Tray 0
24 HDD
Tray 0
24 HDD
1
E
2 1
2
E
Tray 1
24 HDD
Array 1
(48 HDD)
1
E
2 1
2
E
Tray 1
24 HDD
Array 2
(48 HDD)
1
E
2 1
2
E
Tray 1
24 HDD
Array 3
(48 HDD)
Array_0150
Teradata Data Warehouse Appliance 2700 Implementation Guide 37
Chapter 2: System Components
Hardware Components
Figure 9: Node to Disk Array Interconnect: 2-Node Production Clique
2 Quad 6Gbx4 SAS HBAs
0-3
Node 1 Node 2
2 1 2 1
38
1 2 3 4 1 2 3 4
A B
E E
1 2 3 4 1 2 3 4
A B
E E
Tray 0
18 HDD
Tray 0
18 HDD
1
E
2 1 2
E
Tray 1
18 HDD
Array 1
(36 HDD)
1
E
2 1 2
E
Tray 1
18 HDD
Array 2
(36 HDD)
Array_0151
Figure 10: Node to Disk Array Interconnect: Test/Development System
2 Quad 6Gbx4 SAS HBAs
Node 1
0-3
2 1
1 2 3 4 1 2 3 4
A
B
E E
Tray 0
18 HDD
1
E
2 1 2
E
Tray 1
18 HDD
Array 1
(36 HDD)
Array_0152
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Teradata Database Software Components
If a node fails and then resets:
1
2
3
Teradata Database restarts across all nodes.
When the database recovers, the BYNET redistributes the vprocs of the node to the other nodes in the clique.
Processing continues while the failed node is repaired.
Reference Information
Information on...
virtual processors (vprocs)
Is available in...
“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 2700 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
Figure 11: PDE Interface
PDE
OS
1193A001
Teradata Data Warehouse Appliance 2700 Implementation Guide 39
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.
Figure 12: TPA Interface
TPA: Teradata Database
PDE
1193A002
Parsing Engine (PE)
A PE is a virtual processor (vproc). The Teradata Data Warehouse Appliance 2700
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
40 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Teradata Database Software Components
Figure 13: Parsing Engine
SQL Request
Session Control
Parsing
Optimizing
Dispatching
Answer Set Response
Parsing Engine (PE)
System Configuration
Data Demographics
AMP
BYNET
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 2700 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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 41
Chapter 2: System Components
Teradata Database Software Components
Figure 14: Access Module Processors
SQL Request Answer Set Response
Parsing Engine (PE)
AMP
BYNET
AMP AMP AMP
Storage Storage Storage Storage
1193A004
When data is loaded, inserted, and updated, the AMP:
1
2
Receives incoming data from the PE.
Formats rows and distributes them within its storage.
When data is accessed, the AMP retrieves the rows requested by the PE:
1
2
3
The database management subsystem receives the steps from the Dispatcher over the
BYNET.
The database management subsystem processes the steps. The subsystem on the AMP can:
•
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.
42 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 2: System Components
Teradata Database Software Components
Figure 15: Mainframe Interface
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 43
Chapter 2: System Components
Teradata Database Software Components
Figure 16: Network Interface
Network Client
NODE
Network LAN
Adapter
(Hardware)
Gateway
(Software)
PE
PE PE
PE
Host Group
1193A006
44 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 3
Setting Up System Management
Teradata Server Management Client (SMClient) is the principal management tool for the
Teradata Data Warehouse Appliance 2700. SMClient is available through Server Management
Web Services (SMWeb).
The tasks shown in this chapter are required for all Teradata Data Warehouse Appliance 2700 implementations. Perform all tasks and procedures completely and in the order presented.
Assumptions
•
Installation of the Teradata Data Warehouse Appliance 2700 is complete.
•
The CMIC is a virtual machine within the VMS.
•
SMWeb is version 10.02 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 2700.
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 2700 Implementation Guide 45
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
Corporate LAN
SOV
CMIC
Non-SOV
CMIC
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.
46 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Configuring a Workstation for Use with SMWeb
Configuring a Workstation for Use with SMWeb
The following setup procedures are required for running SMWeb applications. The setup 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 2700 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
1
2
3
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 8.0 or later.
From IE, select Tools > Internet Options.
On the Internet Options dialog box, select the Security tab.
On the Security tab, set up the SOV CMIC as a trusted site.
a
Click Trusted Sites, then click Sites.
4
5 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
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
On the Security Settings dialog box, click OK.
On the Internet Options dialog box, click OK.
Teradata Data Warehouse Appliance 2700 Implementation Guide 47
Chapter 3: Setting Up System Management
Accessing the SMWeb Home Page
Setting Up a Firefox Browser
1
2
3
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 10.0 or later.
From Firefox, select Tools > Options.
At Content, select Enable JavaScript.
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.
2
3
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
2700 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.
Download the most current version of JRE 6.
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 49 .
Navigating to the SMWeb Home Page from the SOV CMIC
1
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 47
.
•
The SWS
48 Teradata Data Warehouse Appliance 2700 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 2700 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
Users
Enhanced Users
Access
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.
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 2700 Implementation Guide 49
Chapter 3: Setting Up System Management
Setting Up User Access to SMWeb Applications and Web Pages
User Group
Service Users
<User-Defined
Group
>
Access
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.
•
Network, Devices, and CMICs: Navigate from a non-SOV CMIC to the
SOV CMIC.
•
TVI Connection: Gather information for attachment to incidents.
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
3
4
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.
Log in as a Service User.
Select the Users tab of the Users and Groups window.
50 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Setting Up Server Management Command Line Interface Utilities
5
6
7
Click New User to display the New User dialog box.
At Username, type the name the new user will use to access the system.
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
10
Click Save.
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 LANconnected workstation that you plan to use to monitor or manage a Teradata Data Warehouse
Appliance 2700 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
3
4
Click Command Line Interface for Windows Clients.
When prompted, click Save to save the zip file to a Windows workstation.
Navigate to \Program Files\teradata\sm, and click Save.
Create the directory if it doesn’t exist.
5
6
In an Explorer window, navigate to the saved zip file.
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
8
9
10
Open a command window and navigate to the sm directory.
Under the sm directory, change to the new WinCLIs directory.
Run setup.
When prompted, enter your SMClient login.
Teradata Data Warehouse Appliance 2700 Implementation Guide 51
Chapter 3: Setting Up System Management
Setting Up an Alert Subscription
11
12
When prompted, enter your SMClient password.
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
2
3
4
Display the SMWeb Main page.
Click Command Line Interface for Linux Clients
When prompted, click Save to save the zip file to your local system.
Navigate to /opt/teradata/sm, and click Save.
Create the directory if it doesn’t exist.
5
6
In a shell window, navigate to the saved zip file.
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
8
9
10
11
In the linuxCLIs directory, run cdmod +x * to make the files executable.
In the linuxCLIs directory, run ./setup.
When prompted, enter your SMClient login.
When prompted, enter your SMClient password.
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 Summary Alert Viewer is the primary method for monitoring the health of the system (see
“Monitoring System Health with SMClient” on page 63 ), you can
also configure SNMP traps through the Server Management portlet. See the Teradata Alerts
User Guide, Release 14.10, B035-2210 for more information.
52 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Working with SMClient Default Views
You must set up SMClient default views to monitor the Teradata Data Warehouse Appliance
2700 system.
Setting Up SMClient Default Views
The SMClient Tree View, Summary 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.
3
4
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:
2
http://<hostname or IP address of SOV-enabled CMIC>:9980/CWA/ home.asp
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.
Log in.
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
•
Summary Alert Viewer
•
Status Window
Teradata Data Warehouse Appliance 2700 Implementation Guide 53
Chapter 3: Setting Up System Management
Working with SMClient Default Views
The Tree View, Summary 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 54 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.
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 55
.
The following figure shows the SMClient Tree View for a Teradata Data Warehouse Appliance.
54
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 2700. 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 55
.
Teradata Data Warehouse Appliance 2700 Implementation Guide
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.
The following table describes the operational states displayed in the SMClient Tree View and
Status Window.
Tree View Text
OK
Warning
Status Window
Icons Primary Operational State Description
No action required; the component is operating normally.
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 55
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Tree View Text
Critical
Fatal
Unknown
Status Window
Icons Primary Operational State Description
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.
Immediate action must be taken to return the system to its normal operating state; the component or subsystem has failed.
The component severity level is unknown.
Missing
Powered Off
The component is expected to be present in the system, but is either not present (MISSING) or has not been detected.
The component is powered off.
Alert Viewer
56
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. See “Summary Alert Viewer” on page 60
.
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
The Alert Viewer can be display from the Tree View (Event Mgmt > View Alerts) or from the
Summary Alert Viewer by right-clicking and selecting View Alerts.
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.
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
Alias
Status
Time
Description
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.
•
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.
Date and time the alert was detected
Teradata Data Warehouse Appliance 2700 Implementation Guide 57
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
58 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
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
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 59
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Summary Alert Viewer
60
The Summary Alert Viewer analyzes and summarizes groups of alerts known to occur together during a problem condition. The summary identifies the root cause and gathers the related alerts into an alert bundle, per Site ID, which is reported to the backend.
Alerts with a status of degraded or worse, that do not align with a root cause rule are grouped as situational alerts.
The Summary Alert Viewer automatically displays updates as alert summaries are added, cleared, or autosolved. The Summary Alert Viewer provides a summarized view of the system alerts that meet the root cause rules or situational rules. It allows you to:
•
View the history of active, expired, or cleared alert summaries
•
Filter the alert history
Alert Summary Properties
In the Summary Alert Viewer, alert summaries are listed in rows. The columns in the Viewer show alert summary properties, which include such information as the synopsis of the alert summary affected (Synopsis column), the status (Status column), and the time of the summary (Timestamp column).
If a property you are looking for is not displayed, right-click any column heading in the viewer, and select the property you want to display.
The following table describes only the alert summary 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
Property
Synopsis
Status
Description
A short summary of the problem. he status of the alert summary: Active, Expired, or Cleared.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Property
Type
Description
Identifies the root cause or situational cause.
•
RootCause: A summary of the problem condition with identification of the key/ related alerts. The rules identify the pattern of alerts known to occur together.
•
SituationalCause: Degraded or higher alerts that do not match a root cause.
Within that, each summary is identified.
•
UpdateMore: Sent for an active root cause scenario when more alert types or additional components are seen to contribute to the same problem scenario. Sent when additional alerts types accrue to the situational cause of same or lower severity.
•
UpdateWorse: Sent for an active root cause scenario when a new alert type indicates the problem has worsened. Sent when additional situational alerts occur of higher severity.
•
UpdateRepeat: Sent when there is an active root or situational cause, and additional alerts are repeats of previous alerts accrued to the problem scenario. UpdateRepeats are not sent to the backend.
•
UpdateExpire: Sent when the root cause or situational cause alert summary has expired. Test fault expires in one hour, DBS Restart expires in 20 minutes, and other scenarios expire in 28 days.
•
UpdateClose: Sent when the root cause or situational cause alert summary has been cleared.
Timestamp
The date and time that the alert group was triggered.
Impact
Short impact statement about the problem.
Summary Alert Details
Use the Detail window to understand the meaning of an alert summary, 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 summary, double-click the summary in the Summary Alert Viewer.
Teradata Data Warehouse Appliance 2700 Implementation Guide 61
Chapter 3: Setting Up System Management
Working with SMClient Default Views
Event Viewer
62
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 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.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Monitoring System Health with SMClient
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 Summary 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:
2
3
4
5
6
http://<hostname or IP address of SOV-enabled CMIC>:9980/CWA/ home.asp
Select Server Management Client.
Log in as a Service User.
The SMClient application opens with the Tree View and Summary Alert Viewer displayed by default.
Make sure that the Summary Alert Viewer is displaying the following column headings
(alert summary properties):
•
Synopsis
•
Status
•
Time
•
Timestamp
•
Impact
If these column headings (alert summary properties) are not displayed, do the following to display them:
a
In the Summary Alert Viewer, right-click any column heading.
b
Select a missing alert summary property from the list.
c
for each property you want to add to the Summary Alert
Viewer.
Note: To see more properties in the Summary Alert Viewer, you can extract it from the right pane. To extract the Summary Alert Viewer, select the Summary Alert Viewer title bar, then select Window > Extract and resize the Summary Alert Viewer as needed.
Scroll through the alert summaries shown in the 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 alert summaries recorded by the system since your last review.
Teradata Data Warehouse Appliance 2700 Implementation Guide 63
Chapter 3: Setting Up System Management
Monitoring System Health with SMClient
7
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 the Teradata Alerts User Guide, Release 14.10, B035-2210 for more information.
When you review the alert summaries, right-click and select View Alerts to view them in
Alert Viewer. In the 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 261 .
•
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 64
.
Reference Information
Information on...
SMWeb alert functions
Is available in...
Server Management Web Services User Guide
Determining When to Take Action to Fix a Problem
1
2
3
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.
In Alert Viewer, select an alert with a severity level of Degraded, Critical, or Fatal.
In Alert Viewer, select Functions > View Details, or double-click the alert.
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
•
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
.
64 Teradata Data Warehouse Appliance 2700 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
2
Open a TVI maintenance window. See “Opening a Maintenance Window” on page 65
Follow the procedures in Teradata Data Warehouse Appliance 2700 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
4
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 66
.
When the replacement is complete, see
“Determining Whether Your Action Solved the
Opening a Maintenance Window
When performing system maintenance or replacing customer-replaceable components, open a maintenance window to temporarily stop alerts from being sent to Teradata Services.
2
3
4
5
6
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
Select Server Management Client.
Log in as a Service User.
The SMClient application opens with the Tree View and Summary Alert Viewer displayed by default.
In the SMClient Tree View, select the failed disk drive or power supply.
Select Functions > Maintenance Window. The Maintenance Window dialog box opens.
Set the Start Time and the End Time. Time must be entered in the format
YYYY-MM-DD
HH:MM:SS
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 65
Chapter 3: Setting Up System Management
Working with Customer-Replaceable Components
7
8
9
Enter a Name of the maintenance window.
Click Activate.
If more time is needed to complete the procedure, extend the duration of the open maintenance window by changing the End Time, then clicking Update.
10
Do not exit the Maintenance Window at this time.
Closing a Maintenance Window
1
2
3
When servicing or replacement is complete, close the maintenance window to resume sending alerts to Teradata Services.
In the Maintenance Window, select the maintenance window at Current List.
Click Delete.
Confirm the deletion.
Determining Whether Your Action Solved the Problem
1
2
3
4
5
After replacing a disk array storage drive, disk array power supply, node power supply, or server management power supply, open the Summary Alert Viewer as described in
“Monitoring System Health with SMClient” on page 63
.
Look for the alert summaries related to that component.
Right-click, and select View Alerts.
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.
If the alerts are normal due to the replacement, no action is required. Alerts 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.
If the alerts are normal due to the replacement, clear the alert. In the Alert Viewer:
6
7 a
Select the alert.
b
Select Functions > Clear Alert(s), or right click the alert.
This changes the alert status to Cleared.
In the SMClient Tree View, select the system.
Select View > Status, and check the status window for any continuing problems, or any problems introduced during the replacement.
66 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Opening an Incident
Reference Information
Information on...
SMClient alert functions and maintenance window functions
Is available in...
Server Management Web Services User Guide
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
.
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
5
6
2
3
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
4
Select External Connections.
Log in as a Service User.
The External Connections web page opens.
In the Outbox section, make the following selections:
a
Type: Alert
b c
Time: From Now
Time: to
<select the approximate time an alert identifying the problem appeared in the Alert Viewer>
After the zip file is created, click the link to the zip file and save it to your workstation.
Open an incident and attach the saved zip file. See
Teradata @ Your Service” on page 68
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 67
Chapter 3: Setting Up System Management
Opening an Incident
Opening Incidents Through Teradata @ Your Service
1
2
Access the Teradata @ Your Service web site at: https://tays.teradata.com
Log into Teradata @ Your Service.
3
4
On the Teradata @ Your Service main page, select Service Requests, then select Create.
On the Create Service Request - Step 1 of 5 page, do the following:
5
6
7
8 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
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 a
Indicate whether a support person is already engaged.
d
Click Continue.
On the Create Service Request - Step 4 of 5 page, enter any additional information useful for troubleshooting the problem, then click Continue.
On the Create Service Request - Step 5 of 5 page, do the following:
Verify the information is correct.
b
Add attachments, including the zip file you generated in
Supporting Information for an Incident” on page 67 .
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.
68 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 3: Setting Up System Management
Checkpoint
Reference Information
Information on...
SMWeb alert functions
Is available in...
Server Management Web Services User Guide
Checkpoint
Before leaving Chapter 3: “Setting Up System Management,” make sure that:
Result
Your Internet browser is configured.
Reference
“Setting Up an Internet Explorer Browser on a Windows Workstation” on page 47
“Setting Up Software on a Workstation” on page 48
Java Runtime Environment (32-bit J2SE
JRE) 6.0 or greater is installed on any
LAN-connected workstation that monitors and manages the appliance.
You can access the
SMWeb home page of the SOV CMIC.
SMWeb access privileges are set up.
The
server management CLI utilities are set up on each corporate LAN-connected workstation used to monitor or manage the 2700 system.
SMClient default views are set up to monitor the system.
You can use the Server Management Client
Summary Alert Viewer and Alert Viewer to monitor alerts.
“Navigating to the SMWeb Home Page from the SOV CMIC” on page 48
“Setting Up SMWeb CLI Utilities on a
Windows Workstation” on page 51
See either:
•
“Setting Up SMWeb CLI Utilities on a
Windows Workstation” on page 51
•
“Setting Up SMWeb CLI Utilities on a
“Setting Up SMClient Default Views” on page 53
“Monitoring the Alert Viewer for System
If you do not have these results, return to the section in the Reference column and review that procedure.
Teradata Data Warehouse Appliance 2700 Implementation Guide 69
Chapter 3: Setting Up System Management
Checkpoint
70 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 4
Setting Up Teradata Clients
This section covers the installation and configuration of a subset of Teradata Tools and
Utilities 14.10 software on Windows clients, sufficient for initial implementation of a Teradata
Data Warehouse Appliance 2700 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 Software Management System (SMS) or from
DVDs 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 web sites.
•
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 77 show the configuration procedures
necessary for a basic installation of Teradata Data Warehouse Appliance 2700.
Supported Platforms
To see a list of the client platforms supported by Teradata Tools and Utilities 14.10:
3
4
1
2
5
6
Go to http://www.info.teradata.com
.
Under the Online Publications heading, click General Search.
Type 3119 in the Publication Product ID box.
Under Sort By, select Date.
Click Search.
Open or download Teradata Tools and Utilities 14.10.00 Supported Platforms and Product
Versions, which lists product compatibilities in a spreadsheet format.
Teradata Data Warehouse Appliance 2700 Implementation Guide 71
Chapter 4: Setting Up Teradata Clients
Installation Guidelines
Installation Guidelines
Review the list of client software included with the Teradata Data Warehouse Appliance 2700 and the installation guidelines before beginning client software installation.
Standard Client Software Bundle
Beginning with version 14.10, all Teradata Tools and Utilities products are bundled in one of the following three suites. Each suite is on a separate DVD:
• Teradata Tools and Utilities - Base 14.10
• Teradata Tools and Utilities - Database Management 14.10
• Teradata Tools and Utilities - Tape Storage Management 14.10
If any DVDs are missing, contact Teradata Customer Services at http://www.teradata.com
.
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.10.
User documentation for Teradata Tools and Utilities 14.10 products is available for download from http://www.info.teradata.com
and available on CD in the installation kit.
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 DVD, but the following table lists each package only one time, indicating that they only need to be installed once.
Note: Some individual packages cannot be selected because they are installed as part of TTU,
TPT or other software bundles.
Software Supported on Teradata Data Warehouse Appliance 2700 Install on...
Shared ICU Libraries for Teradata All clients
Teradata GSS Client (Teradata Generic Security Services)
ODBC Driver for Teradata
All clients
All clients
CLIv2 (Teradata Call-Level Interface version 2)
Data Connector
.NET Data Provider for Teradata
BTEQ (Basic Teradata Query)
All clients
All clients
All clients
All clients
72 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Installing Third-Party Software
Software Supported on Teradata Data Warehouse Appliance 2700 Install on...
Named Pipes Access Module
Teradata SQL Assistant
Administrative clients
All clients
Teradata Administrator
Teradata Parallel Transporter (Teradata PT)
Teradata PT Export Operator
Teradata PT Load Operator
Administrative clients
Administrative Clients
Administrative Clients
Administrative Clients
Teradata PT Update Operator
Teradata Index Wizard
Teradata Statistics Wizard
Teradata Visual Explain
Administrative Clients
Administrative Clients
Administrative Clients
Administrative Clients
Note: Applications not shown in this list are not required for basic implementation of the
Teradata Data Warehouse Appliance 2700, 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
Microsoft Windows (or other operating system), available from http://www.info.teradata.com
.
Installing Third-Party Software
Some Teradata Tools and Utilities products require the installation of third-party software.
Before you install Teradata Tools and Utilities, install all of the required third-party software.
You can download most third-party software from the developer's website.
Installing Microsoft .NET Framework
You must install Microsoft .NET Framework 3.5 SP1 or later before you install .NET Data
Provider for Teradata.
Teradata Data Warehouse Appliance 2700 Implementation Guide 73
Chapter 4: Setting Up Teradata Clients
Installing Teradata Tools and Utilities
1
To determine the current version of Microsoft .NET Framework installed on the system, open a command prompt and type APPWIZ.CPL.
The version of Microsoft .NET Framework is displayed in the list of installed programs
2
If the system does not have the correct version installed, download the Microsoft .NET
Framework Version 3.5 SP1 Redistributable Package or Microsoft .NET Framework
Version 4.0 Redistributable Package from the .Net Framework Download website.
3
Select the Microsoft .NET Framework Redistributable Package for your platform.
4
Follow recommendations on the installation page for installing Microsoft.NETFramework
Note: .NET Framework and .NET Data Provider for Teradata are required only for Teradata
SQL Assistant.
Installing Third-Party Software for Teradata Parallel Transporter Base
1
2
Download and install Java 2 Runtime Environment 1.4.2_06 or later from the Java
Downloads website.
[Optional] Download and install Progress DataDirect ConnectXE ODBC driver for
Teradata .
Installing Third Party Software for Teradata Parallel Transporter Wizard
The Teradata Parallel Transporter Wizard software must use the 32-bit Java SE Runtime
Environment (JRE) version 1.4.2_06 or later on the 32-bit and 64-bit Windows platforms, but the PATH to the JRE is not added automatically.
On the 64-bit Windows platform, the Teradata Parallel Transporter Wizard cannot use the 64bit JRE version.
1
2
Download and install the 32-bit JRE from Java SE Downloads website on the 32-bit or 64bit Windows platform.
On a 64-bit Windows platform, add the path to the 32-bit JRE java.exe command to the front of the PATH system environment variable.
Installing Third-Party Software for Teradata WebSphere MQ Access
Module
Note: To display the version of WebSphere that is installed on the system, run the dspmqver command from the command line.
✔
Before you run Teradata WebSphere MQ Access Module, download IBM WebSphere MQ
7.5
and install it according to the instructions in the downloaded package.
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 72 .
74 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Installing Teradata Tools and Utilities
1
2
3
Close all active Windows programs and disable any virus protection software.
If the installation source files are not on the system disk, insert the appropriate DVD.
In the Welcome to Teradata Tools and Utilities dialog, click Install Product.
Note: If the Welcome dialog does not appear shortly after the DVD 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
5
6
In the Choose Setup Language dialog, select a language and click Next.
Read the information in the Welcome dialog, and click Next.
7
Read the information in the Software License Agreement dialog, click Yes to agree and click Next.
In the Choose Destination Location dialog, if the default path shown in the Destination
Folder section is acceptable, click Next (Recommended).
Note: To use a destination location other than the default, click Browse, navigate to the location where the files are installed, click OK, then click Next to end the procedure.
Note: You must have write access to the destination folder, the Windows root folder, and the Windows system folder.
Progress monitors appear during the installation process. No action is required.
8
Consult the table in “Client Software Installation” on page 72
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 Features dialog, click to check the Teradata Tools and Utilities programs to be installed from this DVD. If the checked programs require other programs to be installed from the DVD, those programs will be checked automatically. Some programs cannot be selected individually.
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.
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.
9
10
11
12
Click Install.
Click Finish.
Click Exit in the Welcome to Teradata Tools and Utilities screen.
Remove the media from the drive.
Note: Beginning with Teradata Tools and Utilities 14.10, you can start Teradata Wallet from the Start menu.
Teradata Data Warehouse Appliance 2700 Implementation Guide 75
Chapter 4: Setting Up Teradata Clients
Using the Latest Software Updates
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
3
4
1
2
5
6
To ensure the highest quality and best performance of Teradata Tools and Utilities products, download the most recent updates to Teradata Tools and Utilities from the Teradata Software
Server.
Log on to https://tays.teradata.com
Click Software Downloads.
In the Home tab, click Teradata Client.
Click the Platform.
In the Teradata Client Released Software pane, select the Software base.
Filter the list of available software:
.
•
Select Current to display the most recent release.
•
Select All to display all versions of the software.
7
8
9
Click Submit.
Select the suite you want to download.
Select the Download Type and the Download Readme Files if desired, enter your User Name and E-Mail, then click Submit.
10
11
12
Click Download.
Click Save.
Specify a location to save the downloaded files and click Save to start the download.
Installing the Latest Updates
3
4
1
2
Go to the location where you saved the compressed file.
Read the readme file to see if it contains additional installation instructions or a list of dependencies.
Extract the suite file to a folder.
Run the setup.exe file to install the software.
Downloading the Windows Help Program
This task must be performed for all clients that are running Windows 7, Windows 8, Windows
Vista, or Windows Server 2008. The application is necessary to run online help files with a
.HLP extension.
76 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Configuring Network Name Resolution
1
2
3
Install Teradata Tools and Utilities software before proceeding.
Go to Microsoft Support (Windows Help) .
In the Search box, type
WinHlp32.exe
to locate the WinHlp32.exe file.
Note: Windows Vista users must pass a short validation process before downloading the file. Once validated, specific instructions are given for obtaining the download
4
Run the executable file.
Configuring Network Name Resolution
When Teradata Data Warehouse Appliance 2700 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.
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_
cop
n
dbccop
n
Parameter
nnn.nnn.nnn.nnn
node_name
system_name_copn dbccop
n
Description
The IP address of one of the Teradata Database system nodes.
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.
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.
[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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 77
Chapter 4: Setting Up Teradata Clients
Creating Environment Variables
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 saturn1 saturncop1 dbccop1
240.141.34.102 saturn2 saturncop2 dbccop2
240.141.34.103 saturn3 saturncop3 dbccop3
240.141.34.104 saturn4 saturncop4 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 satnode24 saturncop1 dbccop1
240.141.34.102 satnode34 saturncop2 dbccop2
240.141.34.103 satnode44 saturncop3 dbccop3
240.141.34.104 satadmin saturncop4 dbccop4 or
240.141.34.101 lucy saturncop1 dbccop1
240.141.34.102 ricky saturncop2 dbccop2
240.141.34.103 fred saturncop3 dbccop3
240.141.34.104 ethel saturncop4 dbccop4
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.10\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 for which aliases were assigned 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.
78 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Working with ODBC Data Sources
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 79 .
•
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 81
.
Setting up Teradata as an ODBC Data Source
5
6
7
3
4
1
2
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.
Open the Windows Control Panel.
Double-click Administrative Tools.
Double-click Data Sources (ODBC).
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.
Click Add.
In the Create New Data Source dialog, select Teradata from the list, then click Finish.
In the ODBC Driver Setup for Teradata Database dialog, enter the following:
Field
Name
Description
Name(s) or IP address(es)
Do not resolve alias name to IP address
Recommended Setting
Enter the name by which the
Teradata Data Warehouse Appliance
2700
is known to the network. This is the name that will be displayed for the ODBC data source.
[Optional.] Enter a comment that describes the database system of this data source.
Enter the name by which the
Teradata Data Warehouse Appliance
2700
is known to the network.
Leave this box checked.
The system name is resolved to an appropriate IP address when the
ODBC connection is made.
Teradata Data Warehouse Appliance 2700 Implementation Guide 79
Chapter 4: Setting Up Teradata Clients
Working with ODBC Data Sources
80
Field Recommended Setting
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 is used.
If your site security policy requires a different authentication mechanism. For information on authentication options, see Security
Administration.
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
and
Chapter 10: “Setting Up Users.”
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 specification of a password 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 running the batch load application.
Default Database
Leave this field blank.
The system automatically uses the default database for a user session.
For details on determining the default database for a user, see
“Working with Database Users” on page 187 .
Account String
Leave this field blank.
To use account strings, you must specify accounts for individual users in the user or profile definition. For information on accounts, see
“Working with User Accounts” on page 181 .
Session Character Set
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, use the default ASCII setting.
8
Click OK to complete the configuration of the ODBC data source.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Working with ODBC Data Sources
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
8
9
5
6
3
4
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
2
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.
When the DataDirect ODBC driver installation is complete, open the Windows Control
Panel.
7
Select Administrative Tools.
Select Data Sources (ODBC).
In the Data Sources dialog box, click Add.
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.
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, Snorkle.
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.
Click OK.
Click Finish.
Reference Information
Information on...
configuring the ODBC.ini files for using the
DataDirect ODBC Driver on a Unix client
Is available in...
the chapter about the ODBC Operator in Teradata
Parallel Transporter Reference
Teradata Data Warehouse Appliance 2700 Implementation Guide 81
Chapter 4: Setting Up Teradata Clients
Restarting the Client
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 2700 system.
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:
•
User DBADMIN and other top-level administrative users as part of “Setting Up the
Database Administrator User” on page 93
.
•
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 User 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:
82 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 4: Setting Up Teradata Clients
Checkpoint
•
Mozilla Firefox 3.5 or 4.0 (recommended)
•
Internet Explorer 7 or 8
•
Google Chrome 10
•
Safari 5
Reference Information
Information on...
setup options Teradata Viewpoint not covered in this publication the full range of Teradata Viewpoint portlets and options using Teradata Viewpoint to monitor and manage the database
Is available in...
Teradata Viewpoint Configuration Guide
Teradata Viewpoint Users Guide
•
Chapter 12: “Monitoring the Database”
•
Chapter 13: “Managing the Database”
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.
Microsoft .NET Framework and .NET Data
Provider for Teradata are installed on Teradata client machines.
“Installation Guidelines” on page 72
“Installing Microsoft .NET Framework” on page 73
TTU software is installed on all Teradata clients.
“Installing Teradata Tools and Utilities” on page 74
The TTU software installation includes the latest updates from Teradata @ Your Service.
“Using the Latest Software Updates” on page 76
The Windows Help Program (required for
Windows Vista or later OS) is installed.
Every IP address occupied by the Teradata
Database system has a network alias defined.
Operating system environment variables are defined for CLIv2, which several TTU programs use to access the database.
“Configuring Network Name Resolution” on page 77
“Creating Environment Variables” on page 78
Teradata Data Warehouse Appliance 2700 Implementation Guide 83
Chapter 4: Setting Up Teradata Clients
Checkpoint
Result
The Teradata data source and the external
ODBC data source is defined for the required
ODBC drivers.
Clients where Teradata Tools and Utilities software was installed were restarted.
The administrative clients are set up to access
Teradata Viewpoint
Reference
“Working with ODBC Data Sources” on page 79 .
“Restarting the Client” on page 82
“Setting Up Teradata Clients to Access
Teradata Viewpoint” on page 82
If you do not have any result, review/rerun that procedure.
84 Teradata Data Warehouse Appliance 2700 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”
2
Configure disk space for system-level functions. See
“Allocating Space for System-Level
3
Set up the Database Administrator user. See on page 93
.
“Setting Up the Database Administrator User”
4
Set up Database Administrator privileges. See
to Teradata Viewpoint” on page 102
.
“Setting Up Database Administrator Access
Configuring Default Administrative Settings
Setting Up the Teradata Administrator GUI
1
2
3
From the principal administrative client configured in Chapter 4: “Setting Up Teradata
Clients,” access Teradata Administrator, click Start>Programs>Teradata Administrator.
The Please Select a Data Source dialog box appears. Do the following:
a
In the left field, highlight the alias name for the Teradata Data Warehouse Appliance
2700.
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 2700 Implementation Guide 85
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
If you want to change the location, use the following procedure to relocate the data directory.
1
2
3
4
From the Teradata Administrator main window, click Tools>Options.
Click the Directory tab.
Note the following directory display fields:
•
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.
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.
•
Enable the Lock Logging feature described in
“Enabling Lock Logging” on page 87 .
•
Set the values for some Locking Logger fields as shown in “Setting Up Lock Logging
.
•
Reset the PasswordExpire parameter as shown in
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 260 .
86 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Configuring Default Administrative Settings
Enabling Lock Logging
4
5
Do the following to enable use of the Lock Logger feature described in
Blocks and Delays” on page 235 .
1
2
3
Log on to the Teradata Data Warehouse Appliance 2700 control node, as shown in
“Logging on to the Control Node” on page 251 .
Open a cnsterm Supervisor Window, as shown in step 1 of “Running Database Utilities from cnsterm” on page 250 .
At the prompt, start the DBS Control utility: start dbscontrol
Hold the
Ctrl
key while pressing the
C
key to exit the Supervisor Window.
At the Linux command prompt (#) start cnsterm again, this time specifying the application window in which dbscontrol is running.
6
7
8
9
cnsterm 1
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.
At the dbscontrol prompt, enter the following command to enable the LockLogger Delay
Filter:
MODIFY General 28 = TRUE
At the dbscontrol prompt, enter the following command to set the LockLogger Delay Filter
Time to 1 second:
MODIFY General 29 = 1
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...
All the use of Locking Logger
Is available in...
“Setting Up Lock Logging Parameters” on page 232
.
Changing the PasswordExpire Parameter
1
2
This procedure forces the creation of a private password for user DBC and all other subsequently created users:
Log on to Teradata Administrator as user DBC.
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 2700 Implementation Guide 87
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
3
Enter the following SQL into the query window and click the Run Query button :
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 86 .
6
Restart the database to enable the new password expiration setting, as shown in “Initiating a Manual Restart” on page 260 .
Note: This also enables the Locking Logger parameter changes made in
.
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...
4
5
2, 7 and 8 password control options and how to set them, password format requirements, and other password features the data directory location restarting the database
Is available in...
Chapter 6: “Managing Database Passwords,” in Security
Administration
“Defining the Data Directory” on page 86
.
“Initiating a Manual Restart” on page 260 .
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.
88 Teradata Data Warehouse Appliance 2700 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 187
.
About System-Generated Users
During initial setup, the Teradata Data Warehouse Appliance 2700 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
Crashdumps
DBC
Function
Temporarily stores PDE memory dumps.
Contains:
•
Data Dictionary tables
•
Views and macros
•
System tables
•
Logs and transient journals
SysAdmin
Note: Do not reuse the name SysAdmin.
Sys_Calendar
Contains tables, views and macros for network-based load jobs.
SystemFe
Contains tables and views for daterelated functions.
Contains diagnostic tables and macros for use by Teradata Customer
Service.
~15 MB
~60 MB
Perm Space Default
~1 GB
Can be reset per site needs.
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).
Note: DBC space is not usable for database administration functions.
~40 MB
Teradata Data Warehouse Appliance 2700 Implementation Guide 89
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
Required System-Level Space Allocation Tasks
1
2
Create the spool space reserve. See Creating the Spool Space Reserve
.
Optimize perm space for the crashdumps database according to site needs. See
Perm Space to Crashdumps” on page 91 .
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
3
4
5
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
Determine the perm space owned by user DBC:
a
On the Teradata Administrator main screen, click Tools>Modify User. The Modify
User screen appears.
2 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
, 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
.
Close the Modify User dialog box.
On the Teradata Administrator main screen, click Tools>Create>Database.
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.
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
90 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
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
7 f g
Close the Query window and the Create User dialog box.
To view information about the new database:
a
From the Query window, click the Run Query button .
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 223 .
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...
5
Information on...
the CREATE DATABASE statement strategy and tools for managing space utilization
Is available in...
SQL Data Definition Language Syntax and Examples
•
“About Space Management” on page 223 .
•
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)
Note: To verify the number of nodes, navigate to the SMWeb Home page, click SMClient, and refer to the Tree View, as shown in
.
This equation is based on the following assumptions:
•
32 GB of memory per node
Teradata Data Warehouse Appliance 2700 Implementation Guide 91
Chapter 5: Setting up Administrative Users
Allocating Space for System-Level Functions
2 b c
•
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.
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.
In the left pane of the main screen select the crashdumps database.
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.
3 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 223 .
Keep the Teradata Administrator utility open for use in the
.
92 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
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...
1 and 2 the use and maintenance of the crashdumps database
2 details about perm space the MODIFY DATABASE statement
Is available in...
Chapter 15: “Handling Teradata Crashdumps,” in
Database Administration
Chapter 4: “Space,” in Database Administration
SQL Data Definition Language Syntax and
Examples
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
2
3
4
Create the database administrator profile. See
“Creating the DBADM Profile” on page 93 .
Create the principal database administrator. See “Creating User DBADMIN” on page 95
.
Grant database privileges to the principal database administrator. See
Privileges to User DBADMIN” on page 97 .
Provide Teradata Viewpoint privileges to the administrator. See
Administrator Access to Teradata Viewpoint” on page 102
.
Creating the DBADM Profile
Profiles determine certain system resources available to member users, and can also set password control parameters.
1
2
From an administrative client configured in Chapter 4: “Setting Up Teradata Clients,” log
on to Teradata Administrator as user DBC.
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:
Note: Do not enter values at this time for fields not listed.
Teradata Data Warehouse Appliance 2700 Implementation Guide 93
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
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:
•
Account ID (to assign charges for system time and resources)
•
Date stamp
•
Time stamp
The account string also contains an indication of the general priority level for queries that run under the account, but the actual priority level is controlled by
workload management criteria. See the topics beginning with “Teradata
Integrated Workload Management” on page 238
.
Recommendation: Define at least one account per profile. If necessary, you can define additional accounts later using a MODIFY PROFILE statement.
For more about accounts, including resource cost accounting, see the sections
beginning with “Working with User Accounts” on page 181
.
Password
Spool Space
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.
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
.
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...
94 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Field
Expire
Other password controls
Description
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.
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 d
Do not use the Users in Profile dialog box. You can specify profile membership in
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)
f 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.
Close the Query Window and the Create Profile dialog box.
Reference Information
For step...
Information on...
2 setting up user accounts the default password control values and how to change them
Is available in...
“Working with User Accounts” on page 181
.
Security Administration
Creating User DBADMIN
1
2
From an administrative client configured in Chapter 4: “Setting Up Teradata Clients,” log
on to Teradata Administrator as user DBC.
Create the database administrator as follows:
Teradata Data Warehouse Appliance 2700 Implementation Guide 95
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
a b
From the menu, click Tools>Create>User.
Specify values for the following fields and controls:
Note: Do not enter values at this time for fields not listed.
Field
User Name
Owner
Password
Permanent
Space
Description
Required. The name of the database administrator user.
Recommendation: All administrative procedures in this publication use the name DBADMIN for the principal administrator.
The owner of user DBADMIN, that is, DBC.
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.
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 90
.
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
FALLBACK
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
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.
96 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
c
Click Create.
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.
d
From the Query window, click the Run Query button .
e
Close the Query window and the Create User dialog box.
3
Keep the Teradata Administrator utility open for use in the
“Granting Database Privileges to User DBADMIN” on page 97
, 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...
1 logon to Teradata Administrator
2 user types and characteristics syntax and options for the
CREATE USER statement guidelines for managing of space the default password control values and how to change them
Is available in...
“Configuring Default Administrative Settings” on page 85
.
Chapter 5: “Creating Users and Granting
Privileges,” in Security Administration
SQL Data Definition Language Syntax and
Examples
Chapter 4: “Space,” in Database Administration
Chapter 6: “Managing Database Passwords,” in
Security Administration
Granting Database Privileges to User DBADMIN
1
2
Log on to Teradata Administrator as user DBC.
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 97
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
b
Specify values for the following fields:
Field
Database Name
Object Type
To/From User
Normal
Grant
Description
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.
The object on which the privileges are given.
Select Database from the Object Type drop down list.
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
Specifies the privileges granted to the user. Check the following boxes:
•
Execute
•
Select
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 EXECUTE, SELECT ON "DBC" TO "DBADMIN" WITH GRANT OPTION.
3 d a
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.
From the main window, click Tools>Grant/Revoke>Object Rights.
b
Specify values for the following fields:
Field
Database Name
Object Type
To/From User
Description
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.
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.
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
98 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
Field
All
Grant
Description
Specifies all rights for all objects created in DBADMIN space.
Check the All box.
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 a
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.
From the main window, click Tools>Grant/Revoke>Object Rights.
b
Specify values for the following fields:
Field
Database Name
Object Type
To/From User
Access
Grant
Description
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.
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.
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
Specifies privileges for all DBC tables and views.
Check the Access box.
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 2700 Implementation Guide 99
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 b
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
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.
From the main window, click Tools>Grant/Revoke>System Rights.
c
Specify values for the following fields:
Field
To/From User
All
Grant
Description
The name of the user that receives the privileges.
Select DBADMIN from the To/From User drop down list.
Specifies all rights for all objects created in DBADMIN space.
Check the ALL box.
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;
6 e
GRANT UDTTYPE, UDTMETHOD ON SYSUDTLIB TO DBADMIN WITH GRANT OPTION;
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:
100 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Setting Up the Database Administrator User
GRANT CTCONTROL ON "DBADMIN" TO "DBADMIN" WITH GRANT OPTION;
7 c
Click the Run Query button
Click the Preview Mode button to enable previewing SQL statements before submitting them.
.
Grant privileges on Sys_Calendar, which contains tables and views for date-related system functions.
a b
From the main window, click Tools>Grant/Revoke>Object Rights.
c
Specify values for the following fields:
Field
Database Name
Object Type
To/From User
Normal
Grant
Description
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.
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.
The name of the user that receives the privileges.
Select DBADMIN from the To/From User list.
Allows specification of rights for the named objects.
Check the Select, Insert, Update, and Delete boxes.
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 a
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.
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 2700 Implementation Guide 101
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
Note: User DBADMIN will be prompted to change the temporary password to a permanent, private password at first logon.
e
Click Yes to store the password, then click OK.
f
Click OK to exit the ODBC Data Source Administrator dialog box.
9
10
Click File>Exit to close Teradata Administrator.
Immediately reopen Teradata Administrator, which logs on to Teradata Database as
DBADMIN using the temporary password specified in Step 9 sub step 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.
2
3
For step...
1
Information on...
Is available in...
logon to Teradata Administrator
“Configuring Default Administrative Settings” on page 85
.
system tables and views user privileges
Data Dictionary
Chapter 5: “Creating Users and Granting
Privileges” in Security Administration.
SQL Data Control Language
2 through 6 syntax and options for GRANT
(SQL form) and (Role form)
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.
1
2
Set up administrator client computers as shown in
Chapter 4: “Setting Up Teradata
Create Teradata Viewpoint administrative users and assign roles, as shown in “Setting Up
Teradata Viewpoint Users” on page 217 .
102 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 5: Setting up Administrative Users
Checkpoint
Checkpoint
Before leaving Chapter 5: “Setting up Administrative Users,” make sure that:
Result
The Teradata Administrator GUI is set up on the principal administrative client.
The DBS Control utility fields related to the use of Locking Logger are reset from the default values.
The PasswordExpire parameter is reset and the database restarted to apply the new values.
Crashdumps has perm space assigned to it.
Reference
“Setting Up the Teradata Administrator
“Enabling Lock Logging” on page 87 .
There is a spool space reserve.
“Assigning Perm Space to Crashdumps” on page 91
.
“Creating the Spool Space Reserve” on page 90
.
“Setting Up the Database Administrator
An administrative user called DBADMIN, exists in the database and has:
•
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 102
If you do not have these results, return to the section in the Reference column and review/ rerun that procedure.
Teradata Data Warehouse Appliance 2700 Implementation Guide 103
Chapter 5: Setting up Administrative Users
Checkpoint
104 Teradata Data Warehouse Appliance 2700 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
2
3
4
Create the top level databases that contain all other database objects. See “Working with
Design and create tables to contain data. See
“Working with Tables” on page 112
.
Design and create views to provide user access to data while limiting access to data tables.
See
“Working with Views” on page 123
.
Optionally use the Basic Teradata Query Utility (BTEQ) for database object creation. See
“Working with the Basic Teradata Query Utility” on page 128 .
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 2700 Implementation Guide 105
Chapter 6: Creating the Database Structure
Working with Databases
Database
Tables_Database(s)
Views_Database(s)
Description
•
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
•
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
3
4
From the main screen, click the Preview Mode button to display generated SQL.
Click Tools>Create>Database. The Create Database dialog box appears.
Specify values for the following database parameters.
Syntax Element
Database Name
Owner
Permanent
Explanation
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.
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 95 .
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.
106 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Databases
Syntax Element
Spool
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
Default Journal
Comment
Before Journal
Not applicable.
Recommendation: Specify accounts at the profile or user level. For information
on using accounts, see “Working with User Accounts” on page 181 .
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.
Optional. You can enter text to describe the database.
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
Explanation
Recommendation: Not applicable. Queries running against the Tables database draw spool from the spool reserve of the user.
FallBack
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.
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 2700 Implementation Guide 107
Chapter 6: Creating the Database Structure
Working with Databases
5
Click the Create button to create the database. The Query Window displays a generated
CREATE DATABASE statement similar to the following:
CREATE DATABASE "Tables_Database" FROM "DBADMIN"
AS PERM = 104857600
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
6
7
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.
Close the Query Window and the Create Database dialog box.
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...
All options for setup and operation of
Teradata Administrator
3 and 4 syntax and options for:
•
CREATE DATABASE
•
DELETE DATABASE
•
DROP DATABASE
•
MODIFY DATABASE
4 guidelines for determining database space requirements guidelines for use of journaling
Is available in...
Teradata Administrator User Guide
•
SQL Data Definition Language Syntax and Examples
•
SQL Data Definition Language Detailed
Topics
Database Administration
Database Administration
Creating the Views Database
Use the following procedure to create one or more Views Databases to contain all the views
.
1
Start Teradata Administrator and log on as user DBADMIN.
2
3
From the main screen, click the Preview Mode button
SQL.
to specify display of generated
Click Tools>Create>Database. The Create Database dialog box appears.
108 Teradata Data Warehouse Appliance 2700 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 123
.
For a description of user types, see “About User Requirements” on page 179 .
Owner
Permanent
Space
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 95 .
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
Temp Space
Account
Not applicable. Queries running in the Views database take spool space from the
Spool_Reserve database.
Not applicable.
Not applicable.
Recommendation: Specify account at the profile or user level.
For information on using accounts, see
“Working with User Accounts” on page 181
.
Default Journal
Comment
Not applicable.
Recommendation: Not applicable, because journaling is not specified for views.
Optional. You can enter text to describe the database.
Teradata Data Warehouse Appliance 2700 Implementation Guide 109
Chapter 6: Creating the Database Structure
Working with Databases
Syntax Element
Before Journal
After Journal
FALLBACK
Explanation
Not applicable.
Not applicable.
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.
5
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:
CREATE DATABASE "Views" FROM "DBADMIN"
AS PERM = 0
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
6
7
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.
Close the Query Window and the Create Database dialog box.
Grant access privileges to the Views database, as shown in “Working with Table Access
Privileges for Views” on page 111 . After completing the procedure, return to this section
and continue with the remaining tasks.
Reference Information
For step...
Information on...
All
3 options for setup and operation of
Teradata Administrator
•
CREATE DATABASE
•
DELETE DATABASE
•
DROP DATABASE
•
MODIFY DATABASE an overview of SQL procedures and how they are stored in the database
Is available in...
Teradata Administrator User Guide
•
SQL Data Definition Language Syntax and Examples
•
SQL Data Definition Language Detailed
Topics
SQL Stored Procedures and Embedded SQL
110 Teradata Data Warehouse Appliance 2700 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
3
4 f
On the main screen, click the Preview Mode button
SQL.
Click Tools>Grant/Revoke>Object Rights.
In the Grant/Revoke Objects dialog:
a
to allow display of generated
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.
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 203 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 111
Chapter 6: Creating the Database Structure
Working with Tables
Reference Information
For Step...
Information on...
4 syntax and options for the GRANT
(SQL form) statement database privileges, including those conferred by object ownership
Is available in...
SQL Data Control Language
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 118 .
To ensure data integrity and system security, consider the following general rules when implementing tables:
•
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.
112 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
Table Implementation Overview
1
2
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 112 .
Convert the table definitions for your existing database into Teradata table definitions. See
“Converting Existing Database Tables to Teradata Tables” on page 113
.
3
Become familiar with primary index concepts and requirements. See
Indexes” on page 115
.
“About Primary
4
5
6
Define the primary index for each table. See “About Primary Indexes” on page 115
.
Generate tables using the CREATE TABLE statement. See
“Creating Tables” on page 118 .
After creating and populating a table, monitor perm skew to assess whether the primary
index requires modification. See “Validating Primary Index Selection” on page 123
.
Converting Existing Database Tables to Teradata Tables
2
3
4
5
This procedure uses Oracle as an example to show how you might convert tables created in an
ANSI-compliant database to Teradata.
1
6
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.
Identify the schemas that have objects you want to migrate to Teradata.
Create Teradata databases that correspond to the Oracle schemas and map the schemas to the corresponding Teradata databases.
Identify the DDL for each schema object.
Map Oracle data types to Teradata data types. See “About Teradata Data Types” on page 309 .
Map Oracle table elements to Teradata table elements. See “Creating Tables” on page 118
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 2700 Implementation Guide 113
Chapter 6: Creating the Database Structure
Working with Tables
7
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 117
.
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 115 .
•
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 320
.
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 115
.
•
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.
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 105
.
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 118 .
114 Teradata Data Warehouse Appliance 2700 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
Keys and Foreign Keys” on page 116
.
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 2700 Implementation Guide 115
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
Important element of logical data model.
Used to maintain referential integrity.
Must be unique to identify each row.
Values should not be changed if you want to maintain data integrity and preserve historical relations among tables.
Cannot be null.
Does not imply access path.
Required by Teradata Database only if referential integrity checks are to be performed.
Primary Index
Not used in logical data model.
Used to distribute and retrieve data.
Can be unique or nonunique.
Values can change.
Can be null.
Defines the most common access path.
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.
116 Teradata Data Warehouse Appliance 2700 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.
•
Select columns that are not volatile.
Teradata Data Warehouse Appliance 2700 Implementation Guide 117
Chapter 6: Creating the Database Structure
Working with Tables
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
Improve Query Performance” on page 169 for information on optimizing indexes.
Reference Information
Information on...
indexing:
•
primary indexes
•
partitioned primary indexes
•
secondary indexes
•
join indexes (materialized views) no primary index tables referential integrity
Is available in...
•
Introduction to Teradata
•
SQL Fundamentals
•
Database Design
•
“Using Indexes to Improve Query Performance” on page 169
Database Design
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 151 .
1
2
Logon on to Teradata Database as user DBADMIN using BTEQ. See
.
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); where:
118 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
Syntax Element Explanation
MULTISET
SET
database_name data_type
A MULTISET table allows duplicate rows in compliance with the ANSI
SQL:2008 standard. A SET table does not allow duplicate rows.
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.
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 105
.
If database_name is not specified, the system creates the table in the default database for the current session.
The name of the table to be created.
table_name
[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.
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 309 .
[UNIQUE]
PRIMARY
INDEX
primary_index_ column
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.
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
Teradata Data Warehouse Appliance 2700 Implementation Guide 119
Chapter 6: Creating the Database Structure
Working with Tables
3
4
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 120 .
To automate the creation of data tables by using BTEQ scripts, see “Using BTEQ Scripts to
Create Database Objects” on page 129 .
Set privileges on the table so that only designated administrative users can access the table directly. See
Chapter 10: “Setting Up Users.”
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
.
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
GLOBAL
TEMPORARY
JOURNAL
FREESPACE
DATABLOCKSIZE
Explanation
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.
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.
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%.
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).
120 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Tables
Syntax Element
[UNIQUE] INDEX
PARTITION BY
Explanation
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 169 .
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 115 .
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 2700 Implementation Guide 121
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 129 .
See “Loading a Data From an External ODBC Database” on page 292
and
scripts that load data into this table.
See
“Exporting Data to an External Flat File” on page 301 for a sample Teradata PT export job
script that exports data from this table to an external flat file.
Reference Information
Information on...
an overview of tables, including global temporary and volatile tables
•
syntax, options, and required privileges for:
•
CREATE TABLE
•
ALTER TABLE
•
DROP TABLE
•
RENAME TABLE the default database data protection using:
•
FALLBACK
•
Permanent Journal data types and data type attributes
•
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
Is available in...
•
SQL Fundamentals
•
Database Administration
SQL Data Definition Language Syntax and Examples
SQL Fundamentals
Database Administration
SQL Data Types and Literals
•
“About Primary Indexes” on page 115
•
“Using Indexes to Improve Query Performance” on page 169
“FreeSpacePercent” in:
•
Utilities: Volume 1 (A-K)
122 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Views
Information on...
using the DATABLOCKS option to manage performance and specifying a DataBlockSize value compressing column values column-level and table-level constraints
Is available in...
•
Utilities: Volume 1 (A-K)
•
“Using Multi-Value Compression (MVC)” on page 224 .
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 227 .
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 2700 Implementation Guide 123
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 105 .
For information on materialized views, see
.
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
.
The following procedure shows how to create views using BTEQ:
1
2
Log on to Teradata Database as user DBADMIN using BTEQ. See
Teradata Query Utility” on page 128
.
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
database_name view_name column_name
Explanation
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 105 .
If database_name is not specified, the system creates the view in the default database for the current session.
The name of the view to be created.
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.
124 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with Views
Syntax Element
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 158 .
SELECT clause
Explanation
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.
SELECT clause
(continued)
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 2700 Implementation Guide 125
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.
3
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 129 .
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.
126 Teradata Data Warehouse Appliance 2700 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
2
2
For step...
2
2
2
2
2
2
Information on...
overview of views
•
syntax, options, and required privileges for:
•
CREATE VIEW/REPLACE
VIEW
•
DROP VIEW
•
RENAME VIEW the default database the SELECT statement, including usage of the options and clauses
•
rules for creating, replacing, and using views
•
updatable views
•
WITH CHECK OPTION clause
•
deleting rows using views
(DELETE, Basic/Searched Form)
•
updating rows using views
(UPDATE) specifying locking in views
CREATE RECURSIVE VIEW and
REPLACE RECURSIVE VIEW
Is available in...
•
SQL Fundamentals
•
Database Administration
SQL Data Definition Language Syntax and
Examples
SQL Fundamentals
SQL Data Manipulation Language
SQL Data Definition Language Syntax and
Examples
SQL Data Manipulation Language
•
“Working with Database Locks” on page 158
•
SQL Request and Transaction Processing
SQL Data Definition Language Syntax and
Examples
Teradata Data Warehouse Appliance 2700 Implementation Guide 127
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 129
.
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
2
3
Click Start>Programs>Teradata Client>Teradata BTEQwin.
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:
Log on to Teradata Database.
4
5
.LOGON tdpid/userid where:
•
tdpid is the name by which the Teradata Data Warehouse Appliance 2700 is known to the network.
•
userid is the user id of the user who is logging on.
For example:
.LOGON tdat1/DBADMIN
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:
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:
•
.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.
128 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 6: Creating the Database Structure
Working with the Basic Teradata Query Utility
Reference Information
For step...
Information on...
2, 5 setting session character sets
All
5 options for setup and operation of
BTEQ session transaction semantics
Is available in...
Database Administration.
Basic Teradata Query Reference
“About Session Modes and Transaction
Using BTEQ Scripts to Create Database Objects
You can automate the creation of tables, views, and other database objects using BTEQ scripts.
3
4
The following example procedure uses a BTEQ script to create the sample table from
“Working with Tables” on page 112 .
1
Create a text file named Create_Emp_Table.sql with the following contents:
2
.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:
•
tdpid is the name by which the Teradata Data Warehouse Appliance 2700 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.
Place Create_Emp.bat and Create_Emp_Table.sql in the same folder.
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 2700 Implementation Guide 129
Chapter 6: Creating the Database Structure
Checkpoint
Reference Information
Information on...
starting and exiting BTEQ running batch jobs to submit BTEQ commands and Teradata SQL
Is available in...
“Working with the Basic Teradata Query Utility” on page 128
.
Basic Teradata Query Reference
Checkpoint
Before leaving Chapter 6: “Creating the Database Structure,” make sure that:
Result
You have the following databases:
•
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.
You have views created in the Views database.
Reference
“Working with Databases” on page 105 .
“Working with Tables” on page 112 .
“Working with Views” on page 123
.
If you do not have these results, return to the section in the Reference column and review that procedure.
130 Teradata Data Warehouse Appliance 2700 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 132
.
•
“Converting Built-in SQL Functions” on page 132
•
“Converting Hierarchical Joins” on page 135
•
“Converting Outer Joins” on page 136
•
“Checking the Use of NULLs in Queries” on page 137
•
“Converting Nested Aggregate Operations” on page 137
•
“Converting External Tables to Table Functions” on page 138
•
“Converting Queue Tables” on page 138
•
“Converting Queries to Set Processing” on page 139
•
“Converting PL/SQL Functions” on page 141
•
“General Considerations for Using Teradata SQL” on page 142
Teradata Data Warehouse Appliance 2700 Implementation Guide 131
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 309 .
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
expression
Explanation
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...
Teradata data types data type conversions
Is available in...
•
“About Teradata Data Types” on page 309
•
SQL Data Types and Literals
Chapter 17: “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:
•
Replace the built-in function with an equivalent Teradata SQL function. See “About
Oracle-Equivalent Teradata UDFs” on page 133
.
132 Teradata Data Warehouse Appliance 2700 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 134 .
•
Create a new Teradata user-defined function (UDF) that provides the same functionality
as the existing built-in function. See “Reference Information” on page 136 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 319
Installing Oracle-Equivalent Teradata UDFs
1
2
3
4
5
Verify that your Teradata system has a C or C++ compiler on the node used to compile the
UDFs.
Go to the Teradata Developer Exchange at: http://developer.teradata.com
and use the search function to find “Teradata UDFs for Popular Oracle Functions.”
Download the UDFs (oraudfs_v_4.zip).
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.
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 2700 Implementation Guide 133
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:
2
GRANT EXECUTE FUNCTION ON SYSLIB TO blink;
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
DECODE(a,b,c,d)
GREATEST(a,b)
LEAST(a,b)
SIGN(a)
NVL(a,b)
INSTR(s,c)
LENGTH(s)
LPAD(a,n)
LTRIM(a,c)
LTRIM(RTRIM(a,c))
RTRIM(a,c)
TO_CHAR(x[, f])
TO_DATE(x[, f])
TO_NUM(BER)(x[, f])
TRUNC
MONTHS_BETWEEN(d,e)
Teradata
CASE a WHEN b THEN c ELSE d END
CASE WHEN a >= b THEN a ELSE b END
CASE WHEN a <= b THEN a ELSE b END
CASE a WHEN > 0 THEN 1
WHEN < 0 THEN -1
ELSE 0 END
COALESCE(a, b) or
ZEROIFNULL(n)
INDEX(s,c)
CHAR_LENGTH(s)
CAST (a AS CHAR(n) )
TRIM (LEADING c FROM a)
TRIM (BOTH c FROM a)
TRIM (TRAILING c FROM a)
CAST (x AS CHAR(n) [FORMAT 'f'] )
CAST (x AS DATE|TIMESTAMP [FORMAT 'f'] )
CAST (x AS NUMERIC(n,m) [FORMAT 'f'] )
CAST (x AS DATE FORMAT 'f')
ABS (CAST ((d - e) MONTH(4) AS INTEGER))
134 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Converting Hierarchical Joins
Reference Information
Information on...
UDFs
Procedures and external procedures
Is available in...
“User-Defined Functions” on page 319 .
“About Procedures and External Procedures” on page 317
.
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 2700 Implementation Guide 135
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...
the concept of recursive queries use of the WITH [RECURSIVE] Request
Modifier in a query
Is available in...
SQL Fundamentals
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
Information on...
outer joins
Is available in...
SQL Data Manipulation Language
136 Teradata Data Warehouse Appliance 2700 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...
nulls character string literals
Is available in...
SQL Fundamentals
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 2700 Implementation Guide 137
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...
aggregates aggregate window functions
Is available in...
SQL Functions, Operators, Expressions, and Predicates
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...
UDFs
Is available in...
“User-Defined Functions” on page 319
.
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.
138 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Converting Queries to Set Processing
Reference Information
Information on...
syntax and options for CREATE TABLE
(Queue Table Form) strategy for using queue tables manipulating data in queue tables using:
•
INSERT (push)
•
SELECT AND CONSUME (pop)
•
SELECT (peek)
•
DELETE, UPDATE, or MERGE
Is available in...
SQL Data Definition Language Syntax and Examples
SQL Data Definition Language Detailed Topics
SQL Data Manipulation Language
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...
IF statements nested loops nested procedures or functions
Use...
CASE operations or predicates joins 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 2700 Implementation Guide 139
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 ' '
FROM Deposits A
END
WHERE A.Amt > 0;
THEN ‘UNKNOWN’
ELSE A.Name
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'
END
ELSE 'CUST DEPOSIT'
,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
140 Teradata Data Warehouse Appliance 2700 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...
CASE expressions
SQL predicates joins subqueries
Is available in...
SQL Functions, Operators, Expressions, and Predicates
SQL Functions, Operators, Expressions, and Predicates
SQL Data Manipulation Language
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 139 .
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 2700 Implementation Guide 141
Chapter 7: Converting Queries to Teradata SQL
General Considerations for Using Teradata SQL
Reference Information
Information on...
set processing
Is available in...
“Converting Queries to Set Processing” on page 139 .
UDFs
“User-Defined Functions” on page 319
.
Procedures and External Procedures
“About Procedures and External Procedures” on page 317 .
creating and using macros
“Working with Macros” on page 154 .
General Considerations for Using Teradata SQL
•
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.
Reference Information
Information on...
indexing
Is available in...
•
“About Primary Indexes” on page 115
•
“Using Indexes to Improve Query Performance” on page 169
142 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 7: Converting Queries to Teradata SQL
Checkpoint
Information on...
•
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)
ANSI session mode and Teradata session mode
COMMIT statement
ORDER BY clause
Teradata Database reserved words naming database objects
Unicode support
BTEQ scripts
Is available in...
SQL Stored Procedures and Embedded SQL
“About Session Modes and Transaction Processing” on page 148
.
SQL Data Manipulation Language
SQL Fundamentals
Teradata PT job scripts using the ODBC Driver for Teradata with custom and off-the-shelf ODBC applications
International Character Set Support
“Using BTEQ Scripts to Create Database Objects” on page 129
.
Chapter 15: “Moving Data To and From Teradata
ODBC Driver for Teradata User Guide
Checkpoint
Before leaving Chapter 7: “Converting Queries to Teradata SQL,” make sure that:
Result
Pre-existing data types are converted to Teradata data types.
Built-in functions specific to another RDBMS are converted to Teradata functions.
Hierarchical queries are rewritten in Teradata
SQL syntax.
Queries with outer joins are rewritten using
Teradata SQL syntax.
You know how the NULLS and empty strings in your queries will be interpreted in Teradata.
Nested aggregate operations are converted to
Teradata SQL syntax.
Reference
“Converting Data Types to Teradata
“Converting Built-in SQL Functions” on page 132 .
“Converting Hierarchical Joins” on page 135
.
“Converting Outer Joins” on page 136
.
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 143
Chapter 7: Converting Queries to Teradata SQL
Checkpoint
Result
Oracle external tables are converted to Teradata
Database table functions.
Queue tables from another RDBMS are converted into Teradata SQL.
The migrated SQL is taking full advantage of the parallel processing power of Teradata.
PL/SQL is converted to Teradata SQL and takes advantage of the parallelism and set processing features available in Teradata.
You have reviewed and acted upon other SQL application considerations.
Reference
“Converting External Tables to Table
.
“Converting Queue Tables” on page 138
.
“Converting Queries to Set Processing” on page 139 .
“Converting PL/SQL Functions” on page 141
.
“General Considerations for Using
.
If you do not have these results, return to the section shown in the Reference column and review that procedure.
144 Teradata Data Warehouse Appliance 2700 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...
•
SQL procedures (written using
SQL statements)
•
external procedures (written using C, C++, or Java) embedded SQL using dynamic SQL:
•
with embedded applications
•
in SQL procedures
BTEQ scripts
Is available in...
“About Procedures and External Procedures” on page 317 .
SQL Stored Procedures and Embedded SQL
SQL Stored Procedures and Embedded SQL
“Using BTEQ Scripts to Create Database Objects” on page 129 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 145
Chapter 8: Querying the Database
Working with SQL Queries
Information on...
triggers macros
Is available in...
“Working with Macros” on page 154 .
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 152
.
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.
146 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Working with SQL Queries
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).
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...
multistatement requests submitting single-statement and multistatement requests using BTEQ submitting single-statement and multistatement requests using SQL
Assistant
Is available in...
SQL Fundamentals
Basic Teradata Query Reference
•
“Using SQL Assistant to Submit a Query” on page 151
•
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 2700 Implementation Guide 147
Chapter 8: Querying the Database
Working with SQL Queries
Reference Information
Information on...
•
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
Is available in...
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
Between Teradata SQL and ANSI SQL” on page 147
.
•
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:
•
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
Teradata SQL and ANSI SQL” on page 147
.
•
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.
148 Teradata Data Warehouse Appliance 2700 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 2700 Implementation Guide 149
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...
•
transaction, request, and statement processing
•
transaction processing in ANSI and
Teradata session mode
SQL statements for processing transactions:
•
BEGIN TRANSACTION/END
TRANSACTION
•
COMMIT
•
ABORT
•
ROLLBACK setting the SessionMode field of the DBS
Control Record using the SESSION TRANSACTION BTEQ command setting the Session Mode field in the Teradata
ODBC Driver Options dialog box setting the Session Mode field when defining a .Net data source using SQL Assistant
Is available in...
SQL Request and Transaction Processing
SQL Data Manipulation Language
Utilities: Volume 1 (A-K)
Basic Teradata Query Reference
ODBC Driver for Teradata User Guide
Teradata SQL Assistant for Microsoft Windows User
Guide
150 Teradata Data Warehouse Appliance 2700 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
•
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.
SQL Assistant Capabilities
•
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 128
and
“Appendix C Advanced Features” on page 317 .
Prerequisites
You must install the following software before using Teradata SQL Assistant:
•
Microsoft .NET Framework. See
“Installing Microsoft .NET Framework” on page 73
.
•
.NET Data Provider for Teradata. See
“Installation Guidelines” on page 72
.
•
ODBC Driver for Teradata. See “Working with ODBC Data Sources” on page 79
, 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 2700 Implementation Guide 151
Chapter 8: Querying the Database
Working with Commonly Used Queries
3
4
5
6
Click the Connect button (or select Tools > Connect).
Select the Teradata data source “Setting up Teradata as an ODBC Data Source” on page 79
.
Enter your Username and Password. For example, log on as user DBADMIN.
Do one of the following:
•
Enter an SQL statement in the Query Window.
•
Drag and drop a file from Windows Explorer into the Query Window.
7
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
Reference Information
(or select Tools > Execute Parallel).
Information on...
setting query options setting formatting options for a query executing multiple SQL statements in a single request
Is available in...
Teradata SQL Assistant for Microsoft Windows User Guide
“Using Single and Multistatement Requests” on page 146 .
Working with Commonly Used Queries
The most commonly used and useful SQL queries include:
•
SELECT
•
INSERT
•
UPDATE
152 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Working with Commonly Used Queries
•
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);
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;
Teradata Data Warehouse Appliance 2700 Implementation Guide 153
Chapter 8: Querying the Database
Working with Macros
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
Information on...
the INSERT, SELECT UPDATE, and
DELETE statements
Is available in...
SQL Data Manipulation Language
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
154 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Working with Macros 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 105
.
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 317 and “Differences Between
Macros and Procedures” on page 317
.
Creating Macros
The following procedure shows how to create macros using BTEQ:
1
2
Log on to Teradata Database as user DBADMIN using BTEQ. See
Teradata Query Utility” on page 128
.
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:
Syntax Element
database_name
Explanation
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 105
.
If database_name is not specified, the system creates the macro in the default database for the current session.
Teradata Data Warehouse Appliance 2700 Implementation Guide 155
Chapter 8: Querying the Database
Working with Macros
Syntax Element
macro_name parameter_name data_type
SQL statement
Explanation
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.
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.
The data type of the parameter value.
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.
Syntax Element
data_type_attributes
USING modifier
Explanation
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
Defines one or more parameters used to retrieve data from an external source such as a client data file.
156 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Working with Macros
Syntax Element
LOCKING modifier
Explanation
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 158 .
3
To automate the creation of macros by using BTEQ scripts, see “Using BTEQ Scripts to
Create Database Objects” on page 129 .
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.
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);
Teradata Data Warehouse Appliance 2700 Implementation Guide 157
Chapter 8: Querying the Database
Working with Database Locks
-- 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
2
2
2
2
2
For step...
2
2, 4
2
Information on...
overview of macros
Is available in...
•
Database Administration
•
SQL Fundamentals
SQL Data Definition Language
syntax, options, required privileges for:
•
CREATE MACRO/REPLACE MACRO
•
RENAME MACRO
•
DROP MACRO executing macros the default database data types and data type attributes
SQL Data Manipulation Language
SQL Fundamentals
•
“About Teradata Data Types” on page 309
•
SQL Data Types and Literals
USING request modifier
LOCKING request modifier
SQL Data Manipulation Language
“Working with Database Locks” on page 158
.
optimizing query performance with macros
Database Design
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.
158 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Working with Database Locks
The Lock Manager can lock an object at the following levels:
Lock Level
Database
Table
View
Row Hash
Description
Applies to all tables and views in the database.
All rows of all tables and their associated secondary index subtables are locked.
All rows in a base table and in any associated secondary index and fallback subtables are locked.
All underlying tables accessed by the view, including associated secondary indexes and fallback subtables are locked.
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
EXCLUSIVE
WRITE
READ
Description
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.
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.
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 159
Chapter 8: Querying the Database
Working with Database Locks
Lock Severity
CHECKSUM
ACCESS
Description
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.
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.
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).
160 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Working with Database Locks
Syntax Element Explanation
object_name lock_severity
Specifies the name of the database, user, table, or view to be locked.
Specifies the severity level of the lock to be used. The available lock severities are:
ACCESS, READ, WRITE, EXCLUSIVE, and CHECKSUM.
NOWAIT
SQL_request
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.
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.
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);
Teradata Data Warehouse Appliance 2700 Implementation Guide 161
Chapter 8: Querying the Database
Working with Database Locks
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:
•
Run Lock Display from the Teradata Viewpoint Remote Console portlet
•
Get a report based on dumplocklog data from the Lock Viewer portlet
Reference Information
Information on...
managing locks locking and transaction processing syntax and options for the LOCKING request modifier guidelines for changing default lock assignments syntax and options for the SET SESSION
CHARACTERISTICS AS TRANSACTION
ISOLATION LEVEL statement session isolation level
Is available in...
Database Administration
SQL Request and Transaction Processing
SQL Data Manipulation Language
SQL Data Manipulation Language.
SQL Data Definition Language
SQL Data Definition Language
162 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 8: Querying the Database
Checkpoint
Information on...
specifying locking in views the EXPLAIN request modifier
Is available in...
“Working with Views” on page 123
.
“Using EXPLAIN to Analyze Query Plans” on page 168
.
Utilities: Volume 2 (L-Z)
using the Lock Display (lokdisp) utility to display all active database locks using the Locking Logger utility to set up lock logging using Teradata Viewpoint to investigate locks, blocked users and blocked sessions
•
“Locking Logger” in Utilities: Volume 2 (L-Z)
•
“Setting Up Lock Logging Parameters” on page 232
“Investigating Query Blocks and Delays” on page 235
Checkpoint
Before leaving Chapter 8: “Querying the Database,” make sure that:
Result
You know several ways of invoking SQL statements in Teradata.
You understand the implications of ANSI and Teradata session modes.
You understand the differences between
Teradata and ANSI SQL.
You can execute a query in SQL Assistant.
Reference
“Working with SQL Queries” on page 145
“About Session Modes and Transaction
“About Differences Between Teradata SQL and ANSI SQL” on page 147
“Using SQL Assistant to Submit a Query” on page 151
“Working with Macros” on page 154
You can create macros in BTEQ and SQL
Assistant.
•
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 158
.
If you do not have these results, return to the section in the Reference column and review that procedure.
Teradata Data Warehouse Appliance 2700 Implementation Guide 163
Chapter 8: Querying the Database
Checkpoint
164 Teradata Data Warehouse Appliance 2700 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 165
.
2
Analyze query plans using EXPLAIN and optimize query construction based on the
analysis. See “Using EXPLAIN to Analyze Query Plans” on page 168 .
3
4
After any query optimization change, rerun the query to measure performance differences and determine whether the changes achieved the desired result.
5
Repeat results.
until you get satisfactory performance with correct query
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 2700 Implementation Guide 165
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:
•
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)
Reference Information
Information on...
collecting statistics
Is available in...
Database Administration
166 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 9: Optimizing Query Performance
Using COLLECT STATISTICS to Optimize Query Performance
Information on...
syntax and options for the COLLECT
STATISTICS statement
Teradata Statistics Wizard utility
Is available in...
•
SQL Data Definition Language Syntax and Examples
•
SQL Data Definition Language Detailed Topics
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;
2
Count(*)
-----------
9203
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 2700 Implementation Guide 167
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 Problem Queries” on page 233
.
Generating an EXPLAIN with SQL Assistant
1
2
In the SQL Assistant Query window, enter the SQL query to be EXPLAINed.
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;
168 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Reference Information
Information on...
syntax and options for the
EXPLAIN request modifier interpreting the output of the
EXPLAIN request modifier for various request types
Teradata Visual Explain utility
Is available in...
SQL Data Manipulation Language
SQL Request and Transaction Processing
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.
Costs and Benefits of Secondary Indexes and Join Indexes
Secondary indexes and join indexes can provide many benefits:
•
Lower CPU usage
Teradata Data Warehouse Appliance 2700 Implementation Guide 169
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
•
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:
•
When you create the table. See “Working with Tables” on page 112
.
•
In a CREATE INDEX statement. See
“Creating Secondary Indexes” on page 172
.
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.
170 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query 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 Index Wizard can also validate its recommendations to ensure they actually provide the benefits expected.
Teradata Data Warehouse Appliance 2700 Implementation Guide 171
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
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
2
Log on to Teradata Database as user DBADMIN using BTEQ. See
Teradata Query Utility” on page 128
.
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:
172 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 9: Optimizing Query Performance
Using Indexes to Improve Query Performance
Syntax Element
UNIQUE
index_name index_column_ name database_name table_name
Explanation
Specifies that no two rows in the table can have the same value or combination of values in the indexed columns.
Specifies an optional name for the secondary index.
Recommendation: Specify a name for the secondary index using a standard naming convention.
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
Secondary Index” on page 171 .
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 106
.
If database_name is not specified, the system looks for the table in the default database for the current session.
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 2700 Implementation Guide 173
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.
174 Teradata Data Warehouse Appliance 2700 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
2
3
4
5
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
STATISTICS to Optimize Query Performance” on page 165
.
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.
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.
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.
Analyze the performance of an index to verify that the assumptions for choosing that index are correct. In particular:
•
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 2700 Implementation Guide 175
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. Because the Optimizer always attempts to choose the most efficient method to return the answer to your query, if you notice that the Optimizer consistently chooses a full-table scan instead of using your indexes, this indicates that you need to redesign your indexes or refresh stale collected statistics.
Reference Information
Information on...
overview of indexes designing and using indexes
Is available in...
•
Introduction to Teradata
•
Database Administration
•
SQL Fundamentals
•
Database Design
•
SQL Data Definition Language Detailed Topics
SQL Data Definition Language Syntax and Examples
syntax and options for secondary indexes:
•
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
You collected statistics on tables.
You know how to use the EXPLAIN request modifier to analyze query plans.
Reference
Optimize Query Performance” on page 165
.
“Using EXPLAIN to Analyze Query
.
176 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 9: Optimizing Query Performance
Checkpoint
Result
You know how to implement secondary and join indexes and have considered their costs and benefits.
Reference
“Using Indexes to Improve Query
If you do not have these results, return to the section in the Reference column and review that procedure.
Teradata Data Warehouse Appliance 2700 Implementation Guide 177
Chapter 9: Optimizing Query Performance
Checkpoint
178 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 10
Setting Up Users
This section presents the administrative tasks required to create users and provide them the privileges necessary to access the database.
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 179 .
2
Set up user accounts to track resource usage and assign workload priorities. See
with User Accounts” on page 181
.
3
Set up profiles to define resources, account assignments, and password control parameters for groups of users.
“Working with Profiles” on page 184 .
4
Create database users and assign profiles, space and accounts. See
5
Create roles to define privileges for users groups and grant role membership to users.
“Using Roles to Manage User Privileges” on page 191
.
6
Grant additional privileges that are not suitable for role assignment directly to users. See
“Granting Privileges Directly to Users” on page 199 .
User Evaluation
About User Requirements
The following list identifies five typical user types and job functions.
Functional Category Description
General users
Update users
Database end-users who only need to read the data or to run pre-existing queries or macros to generate reports.
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 2700 Implementation Guide 179
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
Assistant administrators
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.
Administrative users that assist the principal administrator, user DBADMIN,
created in Chapter 4, “Creating User DBADMIN” on page 95
. 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
2
3
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.
Define user resource requirements for use in creating profiles:
•
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 accounts based on job type and system resource requirements. Each profile can include one or more account definitions. See
“Working with User Accounts” on page 181 .
•
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.
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 user privileges in the database at the highest level that is appropriate for the user. For example, if a user requires the same privileges on all views in a database, assign privileges at the database level.
180 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Working with User Accounts
4
Identify groups of users with common database privilege requirements and create roles to define the privileges for groups of users instead of individuals. 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
You can use accounts to:
•
Require the system to tag each session with a number, time stamp and date stamp for
monitoring and accounting purposes. See “Creating Account Strings” on page 182
.
•
Charge for space or processing resources used. See
•
Assign workload management parameters that define database access priorities. See
“Teradata Integrated Workload Management” on page 238
.
Teradata recommends that you devise an account system based on the jobs and resource requirements common to groups of users, and then assign accounts to users in profiles.
Specify one or more accounts for each profile, as required by profile members, using the
CREATE PROFILE or MODIFY PROFILE statement. Specifying an account in a profile
“creates” the account. You can specify the same account in more than one profile, if needed.
The first account listed for a profile is the default account for member users.
Although you can also define accounts in a CREATE USER or MODIFY USER statement, it is not recommended because the presence of an account in a user profile supersedes and invalidates any accounts specified in the user definition.
Active accounts and account assignments are listed in DBC.AccountInfoV.
Reference Information
Information on...
specifying the account string at logon accounts valid accounts and account assignments precedence of accounts in a session
Is available in...
•
Security Administration
•
The logon section in the User Guide for each Teradata tool or utility.
Database Administration
•
See
“Managing User Activity with Accounts” on page 236
.
•
DBC.AccountinfoV in Data Dictionary
“Determining the Account for a User Session” on page 183 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 181
Chapter 10: Setting Up Users
Working with User Accounts
Creating Account Strings
An account string should follow this format:
‘$G
0+account_ID&S&D&H’
If a user or profile definition specifies more than one account string, the individual strings must be separated by commas and the entire list of strings enclosed by parentheses.
Note: When designing your account system, consider how accounts may be used in assigning workload management parameters. See
“Teradata Integrated Workload Management” on page 238
.
where:
Element Description
Required Account String Variables
$G0+ The performance group identifier that determines the default priority level for a user session. This identifier was applicable to previous Teradata
Database releases, but no longer determines the priority level for sessions that use the account.
For Teradata Database 14.0 and up on SLES 11, the session priority is determined by the priority access level defined using the Viewpoint
Workload Management portlet. For information, see
Define Query Priority Level” on page 241
.
Recommendation: Use this section of the account string to note a suggested a default priority level for account members that can be used when constructing workload management rules. This ignored by the system, however, the character count shown to precedes the account ID in this example is required for compatibility with certain administrative tools:
•
$R0+ = Rush (Top)
•
$H0+ = High
•
$M0+ = Medium (default)
•
$L0+ = Low
Note: The 0 and + characters are not actually part of the priority level:
•
The 0 designates the default and only virtual partition (resource partition) allowed on Teradata Data Warehouse Appliance 2700.
•
The + character is a place holder that forces the account_ID to start at the fifth character, required for compatibility with some administrative tools.
182 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Working with User Accounts
Element
account_ID
Description
A four character string that uniquely identifies the account.
Recommendation: You can use the account_ID to differentiate among accounts and describe the account function.
•
Department such as finance (FIN) or marketing (MKT)
•
Job function such as batch processing (B), general use (G), or update (U).
For example:
FINB or MKTU
Note: Although more characters are allowed, using a four-character
account_ID maintains application compatibility and helps prevent the account string from exceeding the 30 character limit when ASE is applied.
Account String Expansion (ASE) Variables
Teradata Database tags each 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. See Database Administration.
&S
&D
&H
The ampersand (&) designates an account string expansion (ASE) variable.
Teradata Database automatically replaces these variables with actual values when the system establishes a session. You can use ASE variables for resource accounting and charge-back, for example, charging users a premium for resource usage during peak hours.
You can use any or all of the following:
•
&S = the session number (9 digits, system generated)
•
&D = the date (for example, July 4, 2009 appears as 090704)
•
&H = the time (2 digits, based on the 24-hour clock)
The system records database activity in the DBC.Acctg table and
DBC.AmpUsageV view by account, substituting the actual value for any specified ASE variables. A new entry appears in DBC.Acctg if a variable value changes during the session, for example, an hour change from 16 to 17.
Each row includes information on CPU, I/O, and vproc usage. See Data
Dictionary.
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 has no account assignment, the session defaults to the first account listed for the owning user or database. Using default owner accounts is not recommended.
•
If the user definition has one or more account assignments, the system uses the first account by default.
•
If the profile for the user also contains one or more account assignments, the first profile account takes precedence over and user accounts and other profile accounts.
Teradata Data Warehouse Appliance 2700 Implementation Guide 183
Chapter 10: Setting Up Users
Working with Profiles
•
If a valid account for the user is specified in the client application, for example, in the
ODBC driver connection presets, the client account specification takes precedence over any applicable user and profile account specifications.
•
If the user has multiple assigned accounts in the user or profile definitions:
•
The user can specify an account in the logon string, which takes precedence. For example:
.logon tdpid/username,password,”account”
•
During a session, the user can submit a SET SESSION ACCOUNT statement to change the session to another assigned account.
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. To assign the profile to a user, specify the profile name in a CREATE or MODIFY USER statement to give membership in the profile to the user.
Profiles can be based on the primary user types such as those shown in “About User
Requirements” on page 179 , or other factors that group users according to database resource
requirements.
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
3
4
From the main screen, click the Preview Mode button generated SQL.
to allow future display of
Click Tools>Create>Profile.
In the Profiles screen, enter values for the profile parameters.
a
In the Profile Name dialog box, enter a unique name for the profile.
Recommendation:
•
The profile name can include such things as the user type or user department to identify its function. For example, WebUser_Profile or FinanceReport_Profile.
•
Consolidate user requirements where possible to avoid the unnecessary proliferation of profiles.
184 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Working with Profiles
b
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 181 .
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, for the FinanceReport_Profile you may want to specify accounts for short decision support queries, small reports, and large monthly reports, as follows:
(‘$M0+FNDS&S&D&H’,‘$L0+FNSR&S&D&H’, ‘$R0+FNMR’)
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.
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
•
General users: 5%
•
Update users: 10%
•
Batch users: 10%
•
Assistant administrative users: 10%
•
Database programmers: 10%
Periodically monitor usage patterns as shown in
Correcting Space Problems” on page 227 , 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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 185
Chapter 10: Setting Up Users
Working with Profiles
Field or Control Description
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 d e
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 93
.
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.
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.
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...
4 syntax and options for the
CREATE PROFILE statement
Is available in...
SQL Data Definition Language Syntax and
Examples
186 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Working with Database Users
For Step...
Information on...
4b using accounts to enforce session priorities
Is available in...
•
“Teradata Integrated Workload Management” on page 238 .
•
“Setting Up Workload Management” on page 239
.
•
Database Administration
Database Administration.
4c
Adding ASE variables to an account string guidelines for determining user space requirements information on monitoring and reallocating space global temporary tables password control options
Database Administration
“About Space Management” on page 223
Database Design
Security Administration
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 129 .
2
3
From the main screen, click the Preview Mode button generated SQL.
Do the following to create a user:
a
Click Tools>Create>User.
b
to allow future display of
In the Create User dialog, specify the values for the required fields and controls.
Field or Control
User Name
Explanation
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 187
Chapter 10: Setting Up Users
Working with Database Users
Field or Control
Owner
Password
Permanent Space
Spool Space
Temporary Space
Account
Explanation
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.
Required. A temporary password. The user is prompted to change the temporary password to a permanent, private password at first logon.
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.
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.
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.
Optional. You can set up user account information to form the basis of various user management options.
Recommendation: If possible, do not specify accounts at the user level, unless the user requires a unique account. Instead specify one or more accounts in the profile in which the user has membership. For information, see
“Working with Profiles” on page 184 .
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.
188 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Working with Database Users
Field or Control
Default Database
Profile Name
Default Role
Default Journal
Startup String
Before Journal
After Journal
Explanation
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.
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.
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
member of only one role.
Optional.
Recommendation: Do not use for initial database implementation.
Teradata Data Warehouse Appliance 2700 Implementation Guide 189
Chapter 10: Setting Up Users
Working with Database Users
Field or Control
FALLBACK
Collation
Time Zone
Default Date Form
Default Character
Set
Explanation
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.
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.
c
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
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 191 .
Reference Information
For Step...
Information on...
3 syntax and options for the CREATE
USER statement
Is available in...
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 181
190 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Using Roles to Manage User Privileges
Do the following to setup roles to manage user privileges:
1
Create roles, as shown in
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 199 .
User Types and Minimum Required Privileges
The following table describes the minimal privileges required by the three basic user types.
User Type
General
Privilege Requirements
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 123 .
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 111 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 191
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
User Type
Update
Batch
Assistant
Administrators
Privilege Requirements
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 111
.
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:
•
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,
Database Administrator User” on page 93
and
“Granting Database Privileges to
to create assistant administrators and grant the privileges they need.
192 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
User Type
Database
Programmers
Privilege Requirements
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
Implicit Privileges
Ownership
Description
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
GRANT
Inherited
When a user creates a database object, Teradata Database automatically grants privileges to:
•
The creator of the object
•
A newly created user or database
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
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 193
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
3
4
5
On the main screen, click the Preview Mode button generated SQL.
Click Tools>Create>Role.
to allow future display of
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:
•
FinanceUser_Role
•
Update_Role
Click the Create button. The Query Window displays the generated CREATE ROLE statement:
CREATE ROLE role_name
6
7
8
9
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.
Close the Query Window and the Roles dialog box.
Repeat this procedure to create the needed roles.
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
3
From the main screen, click the Preview Mode button generated SQL.
Grant privileges to each role as follows:
a
Click Tools>Grant/Revoke>Object Rights.
b
to allow future display of
In the Grant/Revoke Objects dialog, specify values for the following:
194 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Fields and Controls Explanation
Database Name
Object Type
Objects
To/From User
Role
Public
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.
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.”
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.
Not applicable for granting privileges to roles.
Required. The role to which the specified privileges are granted.
Select the name of a previously created role from the displayed list.
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 195
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Fields and Controls Explanation
Normal
Create
Drop
All
Required. Specify the privileges by checking the boxes, based on the guidelines in
“User Types and Minimum Required Privileges” on page 191 .
Recommendation: Consider the privileges that the user may get without
formal granting, as shown in “Types of Privileges” on page 193
, before deciding on what privileges to grant.
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
Access
All But
Optional. Grants administrative privileges on data dictionary tables.
Optional.
Provides basic SELECT and EXECUTE privileges on the specified object.
Optional.
When the All But box is checked, role members receive all privileges except those checked in the Normal, Create, and Drop sections.
c
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.
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"
4
5 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.
Repeat this procedure to grant privileges to all roles.
Close Teradata Administrator or go to
“Granting User Membership in a Role.”
196 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
Reference Information
For Step...
Information on...
3 syntax and options for the GRANT
(SQL Form) statement using roles to manage user access
Is available in...
SQL Data Control Language
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
5
6
3
4
7
On the main screen, click the Preview Mode button generated SQL.
to allow future display of
Click Tools>Create>Role.
In the Roles dialog, select a role from the Role Name drop-down menu.
Click the Users tab.
Select all users that will be members of the selected role, and click Add.
The Query Window will display a GRANT statement similar to:
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
10
11
Close the Query Window and the Roles dialog box.
Repeat this procedure for each role to which a user requires membership.
Log off Teradata Administrator or go to “Defining the Default Role for a User.”
Reference Information
For Step...
Information on...
1 syntax and options for the
CREATE ROLE statement using roles to manage user access
Is available in...
SQL Data Definition Language Syntax and
Examples
Security Administration
Teradata Data Warehouse Appliance 2700 Implementation Guide 197
Chapter 10: Setting Up Users
Using Roles to Manage User Privileges
For Step...
Information on...
2 syntax and options for the GRANT
(SQL form) statement
3 database privileges, including those conferred by object ownership syntax and options for GRANT
(Role form)
Is available in...
SQL Data Control Language
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
5
6
3
4
7
On the main screen, click the Preview Mode button generated SQL.
Click the + next to DBADMIN to display the list of users.
Select the user you want to modify.
to allow future display of
Click Tools>Modify User.
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.
Click the Modify button. The Query Window displays the generated MODIFY USER statement, for example:
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
198 Teradata Data Warehouse Appliance 2700 Implementation Guide
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
10
11
Close the Query Window and the Modify User dialog box.
Repeat this procedure to specify the default role for each user who is a member of a role.
Log off Teradata Administrator or go on to “Granting Privileges Directly to Users.”
Reference Information
For Step...
Information on...
1
7 syntax and options for the SET ROLE statement syntax and options for the MODIFY
USER statement, including the default role using roles to manage user access
Is available in...
SQL Data Definition Language Syntax and
Examples
SQL Data Definition Language Syntax and
Examples
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
Privileges to User DBADMIN” on page 97 .
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 187 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 199
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.
1
2
Use the following procedure to grant SELECT privilege on Sys_Calendar to all Teradata
Database users.
Start Teradata SQL Assistant and log on as DBADMIN.
Enter the following statement in the main query window:
GRANT SELECT ON Sys_Calendar TO PUBLIC
3
4
Click the Execute button
Close Teradata SQL Assistant.
to run the query.
Reference Information
For Step...
Information on...
All Sys_Calendar and the Calendar view
Is available in...
Data Dictionary
Granting Privileges to a User
1
Start Teradata Administrator and log on as DBADMIN.
2
3
4
5
From the main screen, click the Preview Mode button generated SQL.
Click Tools>Grant/Revoke>Object Rights.
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 97
.
Click the Grant button. The Query Window displays the generated GRANT statement similar to:
200 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 10: Setting Up Users
Checkpoint
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
7
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.
Close the Query Window and the Grant/Revoke Objects dialog box.
Log off Teradata Administrator.
Reference Information
For Step...
Information on...
5 syntax and options for the GRANT
(SQL form) statement database privileges, including those conferred by object ownership
Is available in...
SQL Data Control Language
Security Administration
Checkpoint
Before leaving Chapter 10: “Setting Up Users,”
make sure that:
Result
You have assessed database user needs and developed a user management strategy.
Reference
“About User Requirements” on page 179
.
You have created accounts for all user categories
“Working with User Accounts” on page 181
“Working with Profiles” on page 184 .
Profiles define resource parameters for groups of users with similar needs.
Individual database users, including administrators and end users, have been created.
Roles are created in your database, each role has privileges, and users have been granted role membership.
“Working with Database Users” on page 187
.
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 201
Chapter 10: Setting Up Users
Checkpoint
Result
Some users, such as administrators and those who need uncommon object-level privileges, have had privileges granted to them directly.
Reference
“Granting Privileges Directly to Users” on page 199 .
If you do not have these results, return to the section in the Reference column and review that procedure.
202 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 11
Monitoring Database Access
About Access Logging
You can log user access to 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 PCI-
DSS 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 2700 Implementation Guide 203
Chapter 11: Monitoring Database Access
Setting Up Access Logging
Setting Up Access Logging
Running the DIPACC Script
4
5
1
2
The DBC.AccLogRule macro must exist in the database before initiating access logging. You can create this macro with the DIPACC script.
3
Log on to the control node as shown in “Logging on to the Control Node” on page 251
At the Input Supervisor Command prompt, start the DIP utility.
.
Open a cnsterm window as shown in steps 1 and 2 of “Using cnsterm to Run a Database
Utility” on page 252 .
> start dip
Hold the
Ctrl
key while pressing the
C
key to exit the Supervisor Window.
At the Linux command prompt start cnsterm again, this time specifying the application window in which the DIP utility is running.
6
7
# cnsterm 1
At the prompt on cnsterm screen 1, enter the DIP number for the DIPACC script:
> 18
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
8
9
10
Would you like to execute another DIP script (Y/N)?
Enter N at the prompt to exit DIP.
Close the Client Connection window.
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
frequency operation
Description
The frequency of logging during a session.
Valid specifications: FIRST, LAST, FIRST AND LAST, or EACH
The action or comma-separated list of actions which, if present in a user request, triggers logging.
204 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 11: Monitoring Database Access
Setting Up Access Logging
Syntax Element
username object_name
Description
The name of the user, or comma-separated list of users, for which the system logs activity.
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
SELECT . . . FROM Table1
SELECT . . . FROM View1
(where View1 is a view of Table1)
EXECUTE MACRO1
(where Macro1 contains the statement
SELECT . . . FROM Table1)
Result
The system generates a log entry because the query directly names the object that is subject to the logging rule.
The system does not generate a log entry for these queries, even though they access Table1, because the queries do not directly reference 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 203 .
1
Start Teradata Administrator and log on as user DBADMIN.
2
3
On the main screen, click the Preview Mode button
SQL.
b
to enable display of generated
Initiate logging on tables or views that contains sensitive data, such as cardholder data.
a
From the main window, click Tools>Access Logging.
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.
Teradata Data Warehouse Appliance 2700 Implementation Guide 205
Chapter 11: Monitoring Database Access
Setting Up Access Logging
c
Specify values for the following fields:
Field
On Database
Object Type
Object
By User
Denials
With SQL
First
Last
First & Last
Each
Normal field
Description
The name of the database that owns the object that contains the sensitive data.
Select the containing database from the drop down list.
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.
The specific object that contains the sensitive data
Select the name of the specific table or view from the drop down list.
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.
Checking this box logs any denial of access to the object.
Recommendation: Not required. All denials are logged as part of
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.
Checking one of these boxes indicates when the logging is to be performed.
Recommendation: Check Each to conform to the requirement for logging all administrator activity.
Create field
Drop field
Groups field
Lists the normal privileges applicable to the object.
Recommendation: Check all the active (not grayed out) privileges listed except Checkpoint.
Lists the create privileges applicable to the object.
Recommendation: Check all the active (not grayed out) privileges listed.
Lists the drop privileges applicable to the object.
Recommendation: Check all the active (not grayed out) privileges listed.
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"
206 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 11: Monitoring Database Access
Setting Up Access Logging
f e
From the Query window, click the Run Query button .
i
You can optionally display the list of access logging rules at any time as follows:
Close the Access Logging window.
g ii
On the main menu deselect the Preview Mode button display.
On the main window, click Tools>Access Logging.
to suppress the SQL
iii iv
In the Access Logging window, click the Display button to display the logging rules created by the previous steps.
i
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:
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.
4 a iv
Click the Run Query button to execute the SQL statements.
h
Close the Query window.
Initiate logging of any action taken by all users with administrative privileges as follows:
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 2700 Implementation Guide 207
Chapter 11: Monitoring Database Access
Setting Up Access Logging
Field
By User
Denials
Description
The name of the user(s) for which logging is required.
Recommendation: Select all users that have administrative privileges from the
By User field.
Checking this box logs any denial of access to the object.
Recommendation: Not required. All denials are logged as part of
.
With SQL
First
Last
First & Last
Each
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.
Checking one of these boxes indicates when the logging is to be performed.
Recommendation: Check Each to log all administrator activity.
Normal field Not required. Specification of individual privileges is checked automatically when All is checked in the Groups field.
Create field
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"
d e
From the Query window, click the Run Query button
Close the Query window.
.
208 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 11: Monitoring Database Access
Setting Up Access Logging
5
Initiate logging of all invalid access attempts as follows:
a
Specify values for the following fields:
Field
On
Database
Object Type The type of object.
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
Description
The name of the owner of the object that contains the sensitive data.
Recommendation: Check the All box (the default) to log invalid access attempts on all databases and objects.
With SQL
Checking this box logs any denial of access to the object.
Recommendation: Check this box.
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.
Checking one of these boxes indicates when the logging is to be performed.
Recommendation: Check Each to log all access attempts.
First
Last
First & Last
Each
Normal field
Create field
Not required. Specification of individual privileges is checked automatically when All is checked in the Groups field.
Drop field
Groups field
Checking items in the Groups field creates multiple logging rules.
Recommendation: Check All to monitor all privilege checks for administrators.
b
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 2700 Implementation Guide 209
Chapter 11: Monitoring Database Access
Setting Up Access Logging
210
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
By User
Not required. The previous two fields already identify the top-level object.
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
With SQL
First
Last
First & Last
Each
Checking this box logs any denial of access to the object.
Recommendation: Not required. All denials are logged as part of
.
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.
Checking one of these boxes indicates when the logging is performed.
Recommendation: Check Each to log attempts to create or delete system-level objects.
Normal field Not required. Specification of individual privileges is checked automatically when All is checked in the Groups field.
Create field
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"
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 11: Monitoring Database Access
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 b
On the main screen press the Query button open SQL Assistant.
at the bottom of the left menu to
In the SQL Assistant Query window, enter the following SQL statement:
BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.AccLogRule;
8 c
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 LOGGING ON EACH ALL ON TABLE DBC.AccessLogTbl;
BEGIN LOGGING ON EACH ALL ON VIEW DBC.AccessLog;
BEGIN LOGGING ON EACH ALL ON VIEW DBC.DeleteAccessLog;
BEGIN LOGGING ON EACH ALL ON TABLE DBC.EventLog;
BEGIN LOGGING ON EACH ALL ON VIEW DBC.LogOnOff;
b
Click the Run Query button .
9
10
Close the Query Window and the Access Logging dialog box.
Log off Teradata Administrator or go on to “Auditing Database Activity Using DBC Log
Reference Information
For step...
Information on...
All the DIPACC script and the
DBC.AccLogRule macro security logging strategies; logging for directory users and proxy users optional specifications and syntax for the BEGIN LOGGING statement
Is available in...
Utilities: Volume 1 (A-K)
Security Administration
SQL Data Definition Language Syntax and
Examples
Teradata Data Warehouse Appliance 2700 Implementation Guide 211
Chapter 11: Monitoring Database Access
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:
2
SELECT * FROM DBC.AccLogRulesV;
Submit an END LOGGING statement for each BEGIN LOGGING statement in the list that you want to end.
Reference Information
Information on...
use of the END LOGGING statement security logging strategies
Is available in...
SQL Data Definition Language Syntax and Examples
Security Administration
Using Access Logs
About Access Logs
Access logging writes information to the logs shown in the following Data Dictionary views.
View Name
DBC.AccessLogV
DBC.LogOnOffV
Description
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.
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.
212 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 11: Monitoring Database Access
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
b c
. Teradata Administrator opens an SQL Assistant query window.
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.
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
2 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.
You can follow the same procedure shown in
, 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...
All content of the access log tables and views
Is available in...
•
Security Administration
•
Data Dictionary
Teradata Data Warehouse Appliance 2700 Implementation Guide 213
Chapter 11: Monitoring Database Access
Checkpoint
Checkpoint
Before leaving Chapter 11: “Monitoring Database Access,” make sure that:
Result
The database is configured to monitor and log user interactions with the database.
You understand how to disable access logging.
You have a program for regular auditing of the access logs.
Reference
“About Access Logging” on page 203
“Disabling Access Logging” on page 212
“Using Access Logs” on page 212
If you do not have these results, return to the section in the Reference column and review that procedure.
214 Teradata Data Warehouse Appliance 2700 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 2700 system.
•
The RSS data collection system is enabled on the Teradata Data Warehouse Appliance 2700 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
Teradata Viewpoint User 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 2700 Implementation Guide 215
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
TD_SE (Teradata
Solution Engineer)
Includes minimal privileges
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)
Example custom roles
Note: Roles are based on the user types/duties shown in
“About User Requirements” on page 179
.
Database
Administrator
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.
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 2700 system.
216 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 12: Monitoring the Database
Setting Up Teradata Viewpoint Users
Role
Batch User
Update User
General User
Privileges
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
Users who perform miscellaneous insert/update/delete operations.
Suggested role privileges:
•
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
2
Log on as the Teradata Viewpoint administrator and select Admin, which includes a drop down list of administrative functions.
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 2700 Implementation Guide 217
Chapter 12: Monitoring the Database
Working with User Dashboards
3
4
•
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 216 .
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.
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...
the duties typically performed by the user types for which customer roles are recommended
Is available in...
“About User Requirements” on page 179
creating Teradata Viewpoint users, roles, and profiles
•
Viewpoint application Help screens
•
Teradata Database 14.0 Teradata
Viewpoint User Guide
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.
218 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 12: Monitoring the Database
Using Viewpoint Alerts
Creating a Dashboard
From the Teradata Viewpoint portal:
1
2
Use the Add Page option to name the dashboard, for example, MainDashboard.
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 User Guide for procedure details.
3
4
1
2
From the main Teradata Viewpoint portal, select Admin>Setup.
Use Delivery Settings/Email to configure communication with the host SMTP email server.
Select the Teradata system for which you are configuring the alert.
Use Alerts Presets/Action Sets to set up common alert actions, for example, an email message to all administrative users. Then you can use
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 2700 Implementation Guide 219
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
, 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
2
From the Teradata Viewpoint main portal, select Admin>Teradata Systems.
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.
220
Note: The Alert Action name “General Alert” is created using
.
3
Check the Enabled box and click Apply.
Note: See Teradata Viewpoint User Guide for details and options.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 12: Monitoring the Database
Checkpoint
Checkpoint
Before leaving Chapter 12: “Monitoring the Database,”
make sure that:
Result
You have determined which Teradata
Viewpoint privileges are appropriate for user groups at your site.
Database users are configured to access
Teradata Viewpoint.
Teradata Viewpoint users have dashboard pages that display related groups of portlets.
One or more Teradata Viewpoint alerts are setup and you understand how to create additional alerts, as needed.
Reference
“About Viewpoint Monitoring Privileges” on page 216
“Setting Up Teradata Viewpoint Users” on page 217
“Working with User Dashboards” on page 218
“Using Viewpoint Alerts” on page 219
Teradata Data Warehouse Appliance 2700 Implementation Guide 221
Chapter 12: Monitoring the Database
Checkpoint
222 Teradata Data Warehouse Appliance 2700 Implementation Guide
CHAPTER 13
Managing the Database
Database management includes:
•
Space management
•
Query management
•
Account management and cost accounting
•
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
Administrator User” on page 93
.
•
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 2700 Implementation Guide 223
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. You can specify compression for up to 255 values per column.
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 the values 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.
224 Teradata Data Warehouse Appliance 2700 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. Unused space in the data blocks can be compressed.
On Teradata Data Warehouse Appliance 2700 systems, block-level compression is enabled by default, using the following DBSControl Block Compression field settings:
1. BlockLevelCompression = ON
2. CompressPermDBs = UNLESSQBNO (UNLESSQBNO, NEVER,
ONLYIFQBYES)
3. CompressSpoolDBs = NEVER (ALWAYS, NEVER, IFNOTCACHED)
4. CompressGlobalTempDBs = UNLESSQBNO (UNLESSQBNO, NEVER,
ONLYIFQBYES)
5. CompressMloadWorkDBs = UNLESSQBNO (UNLESSQBNO, NEVER,
ONLYIFQBYES)
6. CompressPJDBs = ALWAYS (ALWAYS, NEVER)
7. MinDBSectsToCompress = 32
8. MinPercentCompReduction = 10%
9. CompressionAlgorithm = ELZS_H (ZLIB, ELZS_H, ELZS_S)
10. CompressionLevel = 6 (1-9; Default value = 6)
11. (Reserved for future use)
12. UncompressReservedSpace = 20%
These settings are optimized for a decision support environment, typical of Teradata Data
Warehouse Appliance systems. Teradata recommends that you use the default settings unless you have reason to change them.
Because processing BLC data is CPU intensive, the system does BLC compression/ uncompression with separate hardware instead of using node CPU. In the example shown above, DBS Control Block Compression setting 9 specifies the use of hardware compression.
Updating Space Accounting for BLC
1
2
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.
Log on to cnsterm. See “Running Database Utilities From Viewpoint” on page 249 .
Open the Update Space utility and run the Update Space command for a specific database or all databases:
Teradata Data Warehouse Appliance 2700 Implementation Guide 225
Chapter 13: Managing the Database
Compressing Data to Save Space
UPDATE SPACE FOR {ALL DATABASES | databasename};
For details on UPDATE SPACE, see Utilities: Volume 2 (L-Z).
Reference Information
Information on...
specifying MVC or ALC compression in a
CREATE TABLE or ALTER TABLE statement specifying join index row compression in a
CREATE JOIN INDEX statement all available compression options and how to use them using the Ferret utility COMPRESS and
UNCOMPRESS commands to apply BLC to populated tables using the DBSControl utility to set or modify
BLC parameters using the BlockCompression query band in a
SET QUERY BAND statement to override BLC settings compression usage and restrictions, determining the maximum number of compressed values, calculating space and I/O savings, and comparisons between using MVC and ALC applying compression to various data types using the COMPRESS and DECOMPRESS phrases
Is available in...
SQL Data Definition Language Syntax and
Examples
Database Administration
Utilities Volume 1
Utilities Volume 1
SQL Data Definition Language - Detailed Topics
Database Design
SQL Data Types and Literals
226 Teradata Data Warehouse Appliance 2700 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
Permanent (Perm)
Spool
Temporary (Temp)
Usage
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 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.
Teradata recommends creating a spool space reserve to ensure that there is sufficient spool space to execute user queries. For information, see
“Creating the Spool Space Reserve” on page 90 .
Temp space stores global temporary tables.
Global temporary tables are an advanced feature and not covered in this publication. For information, 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
Total disk space Percentage of total disk space in use across the system
Actions
If system disk space usage moves beyond the normal range (80%), add disk capacity.
Teradata Data Warehouse Appliance 2700 Implementation Guide 227
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Parameter Description
DBC disk space Percent of disk space assigned to DBC currently in use
Actions
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.
1
2
3
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.
Select the system you want to investigate and click Next>.
In the selection menu, select Database: By most space and click Next>.
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
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).
Current Perm
Skew%
A measure of how the perm space for a database distributes across all AMPs. Higher percentages indicate uneven distribution.
Actions
Consider allocating additional perm space to any user or database when it reaches 90%
perm space usage. See “Reallocating Perm
.
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
Fixing Skewed Tables” on page 230
.
4
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.
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 Problem Queries” on page 233
.
228 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Parameter Description
Current Spool% Percentage of available spool space currently being used by each user and database (list)
Peak Spool% Largest percentage of available spool space recently used by each listed user and database since the last reset (default 24 hours).
Actions
Monitor regularly to determine whether certain users regularly exceed 85% spool.
•
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 232
.
•
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
.
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
2
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 184
.
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 2700 Implementation Guide 229
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:
1
•
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.
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" ;
2
3
0
1
AMP
---
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
2
In this example, the answer set displays space allocations by AMP for two tables. The results show that:
•
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
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 219 .
The following table contains some examples of common space usage alerts.
230 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Identifying and Correcting Space Problems
Alert
Crashdumps Space
The crashdumps database needs enough space to contain possible large data dumps that occur during crashes, and which are used in system recovery.
DBC Space
User DBC contains all system tables and logs.
Critical system functions depend on DBC having enough space.
Note: You can set the same alert parameters for
DBCMNGR and
SystemFE, which perform other critical system functions.
Set up three alerts to identify when a database exceeds important space thresholds.
•
All DB 90%
•
All DB 95%
•
All DB 97%
Setup Parameters
Alert rules:
•
Only include databases = crashdumps
•
Current Perm Max% > 70
Note: The threshold is set low because a crashdump can be very large.
Alert Action:
•
•
Do not run twice in 5 minutes
Severity: Medium
Alert rules:
•
Only include databases = DBC
•
Current Perm Max% > 80
Note: Use 90% for SystemFE.
Alert Action:
•
•
Do not run twice in 5 minutes
Severity: Medium
Response to Alert Occurrence
•
Add perm space to the crashdumps database. See
.
•
Purge the crashdumps database of unneeded data and back up needed data to external media.
See Database Administration.
Add perm space to the database.
for information on the DBC space allocation for appliance implementation.
Alert rules:
•
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%)
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.
.
Teradata Data Warehouse Appliance 2700 Implementation Guide 231
Chapter 13: Managing the Database
Managing Query Problems
Managing Query Problems
About Common Query Problems
Query Problem
Stale statistics
Badly skewed data
Poor query construction
Concurrency issues
Result
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 167
.
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 230
.
Poor SQL syntax or missed punctuation can result in bad queries.
Recommendations:
•
Identify bad queries and the users responsible for them. See
“Identifying Problem Queries” on page 233
•
Abort bad queries when required. See “Controlling Problem
.
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
Blocks and Delays” on page 235 .
•
Release a query from the delay cue. See
.
•
Change the priority for a database operation or user. See
“Changing the Account for a Session or Request” on page 238
.
•
Establish more detailed concurrency controls using Teradata
IWM. See
“Setting Up Workload Management” on page 239 .
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:
•
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
232 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Managing Query Problems
Identifying Problem Queries
1
2
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 problem 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.
Monitor query activity using the By Session tab.
Look for problem 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, it indicates a problem query.
•
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
4
5
6
7
Select a session row that shows CPU characteristics indicating a problem query to display the Details View, which provides information about the query, including the user and account that submitted the query.
Select the SQL tab to display the SQL for the query. Examine the SQL for errors and poor construction.
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.
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.
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
.
•
Use the SET SESSION ACCOUNT request to re-assign a poorly-performing query to a
lower-priority account. See “Changing the Account for a Session or Request” on page 238 .
Controlling Problem Queries
To control a problem query:
1
2
In the Query Monitor portlet, click on the session with the identified problem query. The
Details view appears.
You can use the Tools menu to:
•
Change the query priority
•
Abort the query
Teradata Data Warehouse Appliance 2700 Implementation Guide 233
Chapter 13: Managing the Database
Managing Query Problems
•
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
Exclusive
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.
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.
234 Teradata Data Warehouse Appliance 2700 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
Blocked
Description
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 Indicates that the query is in a delay queue caused by a workload rule.
2
3
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
About Blocks and Delays Due to Workload Management Priorities
In addition to blocks that result from normal query execution, blocks can also occur as a result
of the enforcement of workload management rules (see “Teradata Integrated Workload
Single-statement transaction requests held in workload management delay queue do not hold limited resources until after they are released from the queue and begin execution. However, requests that are part of a multi-request transaction (multiple requests embedded between
BT/ET) may hold resources while on the delay queue.
The system detects blocks caused by workload management queuing. You can set Teradata
Integrated Workload Management to log, release, or abort the query when such blocks occur,
Teradata Data Warehouse Appliance 2700 Implementation Guide 235
Chapter 13: Managing the Database
Managing User Activity with Accounts
based on settable parameters. For more information, see “Managing Blocks That Result from
.
Reference Information
Information on...
Locking Logger, Lock Display, and Show Locks utilities managing locks lock and transaction processing
Is available in...
Utilities: Volume 2 (L-Z)
Database Administration
SQL Request and Transaction Processing
Managing User Activity with Accounts
Teradata recommends that you devise an account system based on the jobs and resource requirements common to groups of users, and then assign accounts to users in profiles.
Specify one or more accounts for each profile, as required by profile members, using the
CREATE PROFILE or MODIFY PROFILE statement. Specifying an account in a profile
“creates” the account. You can specify the same account in more than one profile, if needed.
The first account listed for a profile is the default account for member users.
Although you can also define accounts in a CREATE USER or MODIFY USER statement, it is not recommended because the presence of an account in a user profile supersedes and invalidates any accounts specified in the user definition.
Active accounts and account assignments are listed in DBC.AccountInfoV.
You can use accounts to:
•
Require the system to tag each session with a number, time stamp and date stamp for
monitoring and accounting purposes. See “Working with User Accounts” on page 181 .
•
Charge for space or processing resources used. See
•
Assign workload management parameters that define database access priorities. See
“Teradata Integrated Workload Management” on page 238
.
About Account String Structure
An account string should follow this format:
‘$G
0+account_ID&S&D&H’ where:
•
The G in the $G
0+
phrase is the priority indicator.
•
account_ID
is a four character workload descriptor that starts at the fifth character.
•
ID&S&D&H
is a set of optional account string variables.
236 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Managing User Activity with Accounts
Use of the Account String Priority Indicator
In past Teradata Database releases, the priority indicator (the G variable in the example above) defined the default priority level for sessions that used the account.
For Teradata Database 14.0 and up on SLES 11, session priority levels are no longer defined by the account string, but are determined by settings in the Viewpoint Workload Management portlet. You can use the priority character to indicate the priority that is set in Workload
Manager. See “Using Workloads to Define Query Priority Level” on page 241 .
Note: Even if you choose not to use the G variable to indicate priority level, the position is still required as a placeholder, to ensure that the account_ID starts in position 5 in the string, for compatibility with existing applications and related system functions.
Constructing account_IDs to Identify the Assigned Workload
You can construct the account_ID portion of each account string based on the workload assignment that is associated with the account, but it is not required.
Use of the Account String Expansion Variables
The portion of the account string following the account_ID is used for account string expansion (ASE) variables. Teradata recommends the &S&D&H (shown in the preceding example account string) to add a time and date stamp to each session that uses the account.
Various Data Dictionary logs and Teradata Viewpoint portlets use the time and date stamp to track session events.
Other ASE variables are available. See Database Administration.
Using Accounts as Workload Management Criteria
You can use the workload management features in the Teradata Viewpoint Workload Designer portlet to create workloads, throttles, and filters to use in managing query priority, concurrency, and resource consumption.
After creating accounts and assigning them to users, you can assign workload management controls by account. Although you can use other criteria to assign workload controls, accounts are one of the best and easiest to use assignment methods.
For more information, see “Teradata Integrated Workload Management” on page 238
.
Using Accounts for Resource Charge Back
Charge-back billing using accounts permits objective cost allocation of system resources across all users and the ability to charge users for their use of database resources.
The user account string enables you to summarize resource usage by account ID. The system table DBC.Acctg tracks CPU use in seconds and I/O resources expended by a session. The I/O resource tracks the number of AMP-to-disk read and write operations generated by a given session, and charges them to the current account associated with a session.
You can use the DBC.AMPUsage view to access aggregations of logged in DBC.Acctg.
Teradata Data Warehouse Appliance 2700 Implementation Guide 237
Chapter 13: Managing the Database
Teradata Integrated Workload Management
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 (supersedes any accounts defined in the user definition)
•
A user account specified in the logon string, when the user has multiple accounts and does not want to use the default.
•
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.
Changing the Account for a Session or Request
You can use the SET SESSION ACCOUNT statement to change the account during a session.
For example, if a user in the Finance department has the default FIN1 account with a medium
(M) access level:
'$M0+FIN1&S&D&H'
The user can use SET SESSION ACCOUNT to change to a different account string associated with a workload (FINT) that has a top priority (T) access level.
SET SESSION ACCOUNT='$T0+FINT&S&D&H' FOR REQUEST;
A SET SESSION ACCOUNT statement 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.
Investigating Accounts
You can reference the DBC.AccountInfo V to view the list of names for an account or account category and determine whether each name is an individual user or a profile. For example:
SELECT AccountName,UserName,UserOrProfile
FROM DBC.AccountInfoV
WHERE AccountName LIKE '$R%'
ORDER BY AccountName ;
Teradata Integrated Workload Management
The Teradata Data Warehouse Appliance 2700 uses Teradata Integrated Workload
Management (IWM) parameters to manage database queries and enforce priorities.
238 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Setting Up Workload Management
You can define a Teradata IWM rule set, using the Workload Designer portlet in Teradata
Viewpoint, and then configure the rule set to perform workload management functions using the features shown in the following table.
Workload Management Feature Description
Workloads
Session Limits
Throttles
Filters
Each workload defines a set of database access priority rules and the class of queries to which the rules apply.
Defines system-wide limits on the number of sessions that are allowed to be logged on at one time.
Throttles to manage query concurrency, and may cause the system to delay some queries when throttle thresholds are exceeded.
Throttles can be applied system-wide or only to specific workloads.
Filters to reject queries that have certain characteristics before they begin to execute.
Filters are applied system-wide.
Bypasses
Utility controls
Allow some queries to be exempted from rules that would otherwise delay or reject them.
Manages Load/Export utility and console utility work flow separately from other query activity.
The Teradata Viewpoint Workload Designer portlet provides many additional options for controlling workloads. For details, see Teradata Viewpoint User Guide.
Note: The following features, described in the Teradata Viewpoint User Guide, are not available on the Teradata Data Warehouse Appliance 2700:
•
Service Level Goals (SLGs)
•
State Matrix: Query management based on system health and operating period events
•
Non-Tactical Workload Exceptions
•
Virtual Partitions
Setting Up Workload Management
You can use the Teradata Viewpoint Workload Designer portlet to create Teradata IWM rule sets that regulate the database workload.
For details on using the Workload Designer portlet, see Teradata Viewpoint User Guide.
Teradata Data Warehouse Appliance 2700 Implementation Guide 239
Chapter 13: Managing the Database
Creating a Ruleset
Overview of Workload Management Tasks
1
2
3
4
5
6
Determine workload management needs. See “Determining Workload Management
.
Create a ruleset. See
“Creating a Ruleset” on page 240 .
Create one or more workload definitions and assign each one to a priority access level. See
“Using Workloads to Define Query Priority Level” on page 241
.
Create system-level workload management controls.
•
Session limits
•
Throttles
•
Filters
See
“System-Level Workload Management” on page 247
.
Optionally define separate load/export utility and console utility session limits and throttles. See
“Managing Utility Jobs” on page 250
.
Optionally set up block management criteria for handling queries that get stuck in a throttle delay queue. See
“Managing Blocks That Result from Throttle Delays” on page 254 .
Determining Workload Management Needs
Before defining Teradata IWM workload management parameters, you should 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.
•
Monitor database activity 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, to understand blocking and wait time patterns. See the
sections beginning with “About Lock Contentions” on page 234
.
•
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.
If less important queries are preventing critical queries from executing in a timely manner, you can use workload management controls to prioritize queries.
Creating a Ruleset
You must create a Teradata IWM ruleset to contain any workload management rules that you want to define. You can create multiple rulesets, but only one ruleset can active at a time. In the interest of simplicity, Teradata suggests that you start with a single ruleset.
240 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Using Workloads to Define Query Priority Level
After you complete the setup of all rules in the main ruleset, and have activated and tested it, you can create another ruleset that is a variation of the main set to use in adjusting workload management parameters.
Note: This and other workload management set up tasks in this chapter use the Teradata
Viewpoint Workload Designer portlet. For detailed instructions on using the Workload
Designer portlet, see Teradata Viewpoint User Guide.
In the Workload Designer Ruleset view:
3
4
1
2
5
Click on Create.
Add a Name and Description the Ruleset.
Use the default Interval settings.
Use the default Blocker settings.
Defining Bypass rules is optional, but not recommended for the initial implementation.
Note: Database user DBC bypasses all rules by default.
Activating and Deactivating Rulesets
When you complete the creation of the workloads and system-level controls, as shown in the topics that follow, you can use the:
•
Make Ready option to copy the ruleset to the Teradata Database server and to the Ready section.
•
Activate option to make the ruleset take effect on subsequent database queries.
In the Active section, you can use the Deactivate option to remove the effects of a ruleset.
For details, see Teradata Viewpoint User Guide.
Using Workloads to Define Query Priority Level
Workload management is most easily initiated using workload-based rules, that is, a collection of rules that only apply to a subset of database requests.
About Workloads
You can create workloads to represent a class of database requests (queries) with common characteristics. Workloads are useful for:
•
Setting differing access priorities for various classes of queries.
•
System usage accounting to aid such activities as monitoring resource usage patterns, performance tuning, and capacity planning.
Identifying a subclass of queries to which a workload should apply may use some of the same criteria used to create and assign accounts or profiles to user groups. Other classification criteria may include originating application, target database object or query type. For details, see
“Workload Classification Settings” on page 244 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 241
Chapter 13: Managing the Database
Using Workloads to Define Query Priority Level
The system allows you to define up to 250 workloads, however, you should only create a workload where there is a clear need. Usually creating 5 to 20 workloads should be sufficient to efficiently manage system workloads while minimizing workload administration.
Workload Priority Levels
The system prioritizes database queries by the hierarchical tier, and the access level or performance group within that tier, to which a query is assigned by the workload applicable to the query. Queries are processed by the uppermost applicable tier. Queries that do not have an assigned tier and performance group default to Timeshare tier, Medium priority.
242
Top High Medium Low
Internal Tier
The Internal Tier automatically handles system-level functions, for example access privilege checking or querying/writing to the data dictionary, at the highest priority level.
System resources in excess of those required for handling internal system functions fall to the
Virtual Partition Tier.
Virtual Partition Tier
A virtual partition represents a collection of workloads. There is only a single virtual partition available with Teradata IWM. The administrator cannot make changes at this level in the hierarchy. All remaining system resources fall to the Tactical Tier.
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Using Workloads to Define Query Priority Level
Tactical Tier
The Tactical Tier is an optional tier that may not contain workloads in some Teradata
Database sites. This tier is intended exclusively for highly-tuned, very short duration tactical queries – primarily queries that support single-AMP and few-AMP operations.
Workloads running at the Tactical level receive all the resources they need, with the remaining resources passed down to the next level. Because of this unique characteristic, special care needs to be taken when defining Tactical workloads.
•
Only highly-tuned, very short, single-AMP or few-AMP queries should be assigned to a
Tactical workload.
•
Do not use Tactical workloads for load utilities.
•
As a safe guard, adjust the exception thresholds, if needed, so that they effectively demote queries with non-tactical characteristics from Tactical to Timeshare.
•
Monitor tactical exceptions regularly, adjust the exception thresholds, when needed.
System resources that remain after executing Tactical Tier queries fall to the Timeshare Tier.
Timeshare Tier
The Timeshare Tier is intended for all non-tactical queries. It is normal for the Timeshare Tier to prioritize nearly all queries on most database systems. Prioritization is done by means of sub-tiers called access levels, each of which represents a prioritization level.
The Timeshare Tier has four predefined access levels that you can assign to sessions using
“Classification” settings.
Timeshare Access Level
Top
High
Medium
Low
Access Weight
8x
4x
2x
1x
The access weight determines the relative processing resource allocation available to each access level and the frequency with which the system offers CPU to jobs running at that level.
Access level does not predict actual CPU usage or consumption. Lower level jobs receive more
CPU when higher level jobs are not using it.
The following is a typical set of access level assignments:
•
Top: Emergency jobs
•
High: Short (sub-second) queries
•
Medium: Longer queries
•
Low: Large batch jobs and reports.
Note: These assignments are shown only as examples. Always assign access levels according to site-specific business needs.
Teradata Data Warehouse Appliance 2700 Implementation Guide 243
Chapter 13: Managing the Database
Using Workloads to Define Query Priority Level
After completing the initial setup of Timeshare Tier workloads, you can easily change a workload access level by dragging the workload from one level and dropping it into another.
Workload Classification Settings
Use the options on the Classification tab to assign workload management parameters. If you do not specify a classification, the rules defined for the parameter apply globally.
Classification Criteria
Source
Target
Query characteristics
Query Band
Utility
Description
The query source.
Can be one of the following
:
•
Account name
•
Account string (includes ASE variables)
•
Application
•
Client ID
•
Client IP address
•
Profile name
•
User name
The query target:
•
Database object (database, table, view, macro, stored procedure)
•
Sub-criteria related to the object, for example: “Unconstrained product join against table XYZ.”
For example, statement type, join type, or full table scan.
Criteria that can be specified in a SET QUERY BAND statement.
The utility that is the source of the query, for example, TPT Load operator.
Recommendations:
•
You can use as many of the workload classification criteria as required, but Teradata recommends that you simplify classification where possible so that the effects are clear.
•
Request source and query band classification criteria are the most exact and predictable.
Use one of these classification methods whenever possible.
•
Use the Target, Query Characteristics, and Utility criteria mainly to differentiate subclassifications of request source and query band criteria, rather than as primary criteria.
Creating a Workload
3
4
1
2
In the parent ruleset, select Workload.
Select Create Workload.
In the General tab, enter a name and [optional] a description.
Under Workload Management Method, select Tactical or Timeshare, based on how you want to assign priority for queries to which the workload should apply. See the descriptions in
“Workload Priority Levels” on page 242 .
244 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Using Workloads to Define Query Priority Level
5
6
7
8
9
Click Save.
If you selected Timeshare in step 4
, the newly created workload appears in the Medium access level in the Timeshare section of the Workload Distribution screen. You can drag and drop the workload to a different access level if required.
Select the Classification tab and specify the criteria needed to apply the workload to a class
of incoming queries, as discussed in “Workload Classification Settings” on page 244
.
Click Save.
Optionally create a workload throttle, as shown in the following topic.
Using Workload Throttles
A workload throttle is an attribute of a specific workload or workload group, which only controls queries that are classified for that workload. Otherwise, workload throttles function the same as system throttles. You can apply a workload throttle to a single workload or a workload group.
Recommendations for workload throttles:
•
Create workload throttles first and then introduce system-level throttles later, if needed.
•
Avoid throttling Tactical workloads, which are supposed to have priority among concurrent queries.
•
Throttle Low and Medium timeshare workloads to avoid a shortage of AMP worker tasks.
For a detailed description of options and usage, see “Working with Throttles” on page 248
.
Also see
“Using Workload Utility Throttles” on page 253
.
Creating a Workload Throttle
1
From the Workload screen, select the Throttles tab.
2
Set a throttle to limit concurrent queries classified into this workload or select an existing group throttle to make this workload a member of the group throttle.
Defining Workload Exceptions
A workload exception can be used to change a workload control parameter for an atypical condition that may arise among a set of queries that would normally be assigned to a workload.
Note: Teradata Integrated Workload Management on the Teradata Data Warehouse Appliance
2700 only supports the definition of exceptions on Tactical workloads.
You can use the Tactical Exception tab to express workload exceptions as thresholds. You cannot create an Exception for a non-Tactical workload.
Teradata Data Warehouse Appliance 2700 Implementation Guide 245
Chapter 13: Managing the Database
Using Workloads to Define Query Priority Level
Setting Explanation
CPU seconds consumed by the query
Can be set to either:
•
CPU per node
The default value is 2 seconds.
•
CPU (sum over all nodes)
The default value is the number of nodes multiplied by the CPU per node value.
Physical bytes of I/O transferred
Can be set to either:
•
Physical bytes of I/O transferred per node
The default value is 200 MB.
•
Physical bytes of I/O transferred (sum over all nodes)
The default value is the number of nodes multiplied by the I/O per node value.
Note: The values of these parameters (either defaults or saved custom values) remain in effect until they are changed. If you add nodes to the configuration, the system does not automatically recalculate the per node values.
To complete the exception definition, you must specify an alternate tactical workload, to which a query transfers if it exceeds the threshold, using “Change Workload.”
Usage Notes
The normal use of tactical exceptions is to differentiate among tactical queries that may otherwise be subject to the same workload. For example:
•
For a tactical workload where the Source specifies an application that is normally used to submit low CPU usage queries, you can use an exception to detect queries with higher
CPU usage and route them to a lower priority workload.
•
For business critical applications that may sometimes need to consume large amounts of
CPU and I/O. You can set the values small for most queries in the workload and create an except to allow extra resources.
For additional information, see “Workload Designer” in Teradata Viewpoint User Guide.
Specifying an Evaluation Order
2
3
If you create several workloads, a query attempting to run on the database may be subject to more than one of the workloads. To avoid uncertainty as to which workload a query should be assigned to, define a workload Evaluation Order. When multiple workloads apply to query, the system always uses the workload closest to the top of the list.
1
In the active ruleset that contains the workloads you want to prioritize, click on the
Workloads tab.
Click on the Evaluation Order tab.
In the list of workloads, do one of the following to create the needed evaluation order:
246 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
System-Level Workload Management
•
Drag and drop workload names to reorder the list.
•
Click in an item number box, and after highlighting the number you want to change, enter the new number.
4
Click Save.
Note: You can also set the evaluation order for utility management rules. For information on workload management for Utilities, see
“Managing Utility Jobs” on page 250 .
System-Level Workload Management
In addition to managing queries at the workload level, you can also create system-level controls. Workload-based controls only apply to queries assigned to one or more workloads.
System level controls apply to all queries attempting to access the database.
Teradata IWM system-level control methods include the following.
Method
Query Session Limits
Throttles
Filters
Bypass
Function
Rejects queries if the system workload exceeds specified limits.
Delays or rejects queries if the system workload exceeds certain concurrency criteria.
Reject queries that have certain characteristics.
Allows queries in a defined bypass classification to avoid restrictions imposed by a system-level control.
Working with Query Session Limits
You can use the Sessions tab in a ruleset to create query session limits. Although query session limits, like throttles, are based on session concurrency, they can only reject queries rather than delay them. If a query session limit rejects a session, the user must log on again to rerun it.
You can create global query session limits, or you can use Source classification criteria to apply the effects of the limits more specifically. See
“Workload Classification Settings” on page 244 .
For example, you can limit the:
•
Number of concurrent sessions that can be logged on to the database.
•
Number of concurrent utility jobs.
•
Number of concurrent sessions for a specific utility job.
•
Order of precedence of utility session rules.
Note: State-based parameters are not available on a Teradata Data Warehouse Appliance 2700.
For details on setting session limits, see Teradata Viewpoint User Guide.
Teradata Data Warehouse Appliance 2700 Implementation Guide 247
Chapter 13: Managing the Database
System-Level Workload Management
Working with Throttles
Throttles manage query concurrency, and can either reject or delay queries when specified concurrency limits are exceeded. When system activity falls below the throttle concurrency limit, the system begins to run delayed queries in the order they were delayed. If a query has been delayed and then begins to run, it cannot be delayed again.
Use workload throttles primarily to prevent a large number of relatively low priority queries from running at the same time, leaving no available resources for higher priority queries.
Note: If a query is subject to multiple throttles, it must be allowed by all throttles before it can run.
Example Throttle Rules
A throttle limits the number of concurrent queries in a filter classification. When the throttle limit is reached, additional affected queries go into the delay queue.
You can create throttles to limit concurrency according to throttle classification, for example:
•
Limit a specific user (source classification) to having no more than 10 sessions at a time
(query session limit).
•
Limit the number of application X sessions (source classification) simultaneously executing against a table (target classification).
•
Allow no more than 3 concurrent data mining queries (source classification), because data mining is slow and uses significant resources.
•
Limit queries based on query characteristics, for example, statement type, step row count, or join properties.
Comparing System Throttles to Workload Throttles
You can create throttles to reject or delay queries at either the workload or system level.
Although these two types of throttle function in similar ways, there are some differences.
Throttle Type
Workload Throttle
System Throttle
Description
Controls query concurrency only for the associated workload.
A workload throttle is subject to the same classification criteria as defined for the parent workload.
Controls query concurrency for all queries, or for a specified subset of queries, across the entire system.
System throttles are most useful during temporary system-wide situations. Sessions that are already in the process of execution are not affected.
System throttles can make full use of all classification criteria.
Do not use system throttles for utilities.
248 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
System-Level Workload Management
Default System Throttles
The following throttles are created by default on Teradata Data Warehouse Appliance 2700 systems, and automatically apply globally.
Throttle all at 52:
•
Limits the database to 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 timeshare access level queries with estimated processing time > 1 second:
•
Sets a limit of 30 concurrently executing H, M, or L queries that have an estimated processing time > 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 Top query of any size.
7
8
5
6
9
3
4
1
2
Creating a System Throttle
Use the following procedure to create a system throttle. To create a workload throttle, see
From the toolbar in the parent ruleset, click on Throttles.
Click Create System Throttle.
Enter a name.
Select a Rule Type option: Collective, Individual, or Member.
•
Collective applies the throttle to all users that meet the criteria.
•
Individual applies the throttle individually to each user or database object.
•
Member applies the throttle to individual members of an account or profile group classification.
Click Save.
Click the Classification tab.
Specify the needed classification criteria.
Click OK.
Click Save.
Working with Filters
A filter rejects applicable queries before they begin running. Filters work in a way similar to throttles, except that filters cannot delay a query, only reject the query or let it run.
You can only define system-level filters. Workload filters are not allowed.
Because filters prevent applicable queries from ever running, they are not commonly used. If you do use filters, you can create Bypasses to exempt certain query classifications from being affected by a filter.
Teradata Data Warehouse Appliance 2700 Implementation Guide 249
Chapter 13: Managing the Database
Managing Utility Jobs
Filters use the same classification criteria as are used for workloads. See
Classification Settings” on page 244
.
For example, you can use classification criteria to define filters that prohibit:
•
A specific user (source classification) from running a query with an estimated processing time of longer than 15 minutes (query characteristic classification).
•
Any query without join constraints (query characteristic) that runs against a large complex table (target).
For information on creating filters and using Warning Mode, see Teradata Viewpoint User
Guide.
Use of Warning Mode During Initial Implementation
When creating a filter, you can specify Warning Mode for use during initial implementation.
This mode returns a warning message when the filter affects a query rather than rejecting the query, so you can determine how the filter is functioning without disrupting users.
Once you determine that the filter is working as planned, you can remove it from Warning
Mode and allow the system to reject affected queries, as designed.
Managing Utility Jobs
You can use Teradata IWM to manage the concurrent use of certain Teradata utilities, at a system level or for specific workloads.
Protocol
Load/Export Utilities
FastLoad
Applications
MultiLoad
FastExport
Backup/Restore
Console Utilities
Console utilities
•
Teradata Parallel Transporter Load Operator
•
FastLoad utility
•
JDBC FastLoad
•
CSP Save Dump
•
Teradata Parallel Transporter Update Operator
•
MultiLoad utility
•
Teradata Parallel Transporter Export Operator
•
FastExport utility
•
ARCMAIN
•
Supported BAR applications
For example:
•
Check Table
•
Scan Disk
250 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Managing Load/Export Utility Jobs
Note: Teradata IWM utility management functions are also supported for third-party load/ export utilities that use the Teradata Parallel Transporter Application Programing Interface
(API).
Note: The TPump and Teradata PT Stream operator function using the SQL protocol, and can be managed using standard query-oriented workload management tools, for example,
Workloads, session limits, throttles, and filters, as shown in the topics preceding this one.
Managing Load/Export Utility Jobs
Workload management of load/export utility concurrency includes:
•
Utility Limits (system-level utility job throttles)
•
Utility Session Limits (system-level utility per-job session throttles)
•
Utility Concurrency limits (workload utility throttles)
Consider the following when determining how best to use throttles to manage utility jobs.
•
Use system-level utility throttles to set general utility session concurrency limits, for example, for all users or all accounts.
•
Use workload throttles for more detailed utility concurrency control, for example, for use of utilities by a specific user or account.
Using Utility Session Limits to Manage Load/Export Jobs
The Teradata Data Warehouse Appliance 2700 has several default utility limits, based on utility protocol. You can also create custom session limits.
Default Utility Limits by Utility Protocol
Utility Protocol
FastLoad + MultiLoad
Session Limit
30
FastLoad 30
MultiLoad 30
FastExport
Backup/Restore
60
350
1
2
Creating Custom Utility Session Limits
If possible, use the default utility session limits listed in the previous topic. If the default limits are not sufficient, you can create custom utility session limits. For example:
On the Utility Sessions tab, click the Utility Sessions tab.
On the New Utility Sessions screen:
Teradata Data Warehouse Appliance 2700 Implementation Guide 251
Chapter 13: Managing the Database
Managing Load/Export Utility Jobs
3
4 a b
Enter a name for the rule, for example, Sam_Update_Limit.
Select a utility, for example, TPT Update Operator.
c
Enter a Max Sessions limit, for example, 3.
d
Click Save.
On the Classification tab, specify the applicable user name, for example Sam, as the
Request Source.
Note: If you do not specify a request source, the limit applies to all jobs for the specified utility.
[Optional] On the Utility Sessions Evaluation Order tab, you can change the evaluation order for the new custom session limit rule you created by moving within the list of names.
About Utility Workloads
Observe the following when using Teradata IWM Workloads to manage utility sessions.
The Teradata IWM handles the entire load/unload process as one unit of work. The unit of work starts at the BEGIN LOADING/MLOAD/EXPORT3 statement on the control SQL session. It ends after the END LOADING/MLOAD/EXPORT statement. Therefore, a utility unit of work spans multiple SQL statements.
Only the first SQL statement of a unit on the control SQL session is subject to the Utility classification criterion used to assign a utility workload. Subsequent statements of the unit are automatically assigned to the same utility workload.
SQL statements outside the load/unload unit as well as SQL statements from any auxiliary
SQL session are assigned to a different workload(s).
This also applies to workload throttles. See “Using Workload Utility Throttles” on page 253 .
Using Workloads to Manage Load/Export Job Priorities
You can use Teradata IWM Workloads to manage load/export job priorities. For example:
1
2
Create the Workload as shown in “Creating a Workload” on page 244
Specify the needed classification criteria.
a
For Utility: Specify the utility to which you want to assign the workload priority, for example, TPT Load operator.
b
Specify the Workload Management Method as Timeshare. Do not classify utility workloads to the Tactical tier.
c
[Optional] For Target: Specify the database, table, or view (except BAR utilities)
d
[Optional] For Query Band: Specify query band criteria.
e
[Optional] For Request Source: If you specify a source, for example a user, only utilities that come from that source are prioritized.
Note: The following classification criteria are not available to utility workloads:
•
Query Characteristics: All
252 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Managing Console Utilities
3
•
Targets: Macro and stored procedure
Click Save.
4
[Optional] Add a workload utility throttle, as shown in
Using Workload Utility Throttles
.
Using Workload Utility Throttles
Workload throttles are useful mainly to create very detailed concurrency controls, for example, for a specific user. Otherwise you should use system-level throttles to control utility concurrency.
Applicable throttle counters (system and workload throttles) are only checked and incremented at the beginning of a work unit. Throttle counters are decremented at the end of a unit. For backup/restore, the entire script is treated as one unit. For an explanation of utility workload units, see
“About Utility Workloads” on page 252 .
Note: Teradata IWM sees a utility job as a single unity of work. Only the initial SQL statement in a load/export job is subjected to the workload classification criteria.
1
2
Creating a Workload Utility Throttle
You can create a workload utility throttle to control a specific type of utility for a specific user, for example:
3
For the workload Request Source classification criteria, specify the name of the user.
For the workload Utility classification criteria, specify the utility for which you want to limit concurrency, for example, TPT Load operator.
Set the workload throttle to the maximum number of concurrent utility sessions you want the user to run, for example, 3.
Managing Console Utilities
Console utilities such as Scandisk (Ferret) and Checktable do not logon and run the normal paths through the Parser/Dispatcher like query requests, so they bypass the classification step that assigns requests to workloads. Because of this, you must establish workload priorities for console utilities differently than for load/export utilities.
You can use the Console Utilities tab in the Workload Designer portlet to enable workload priorities for console utilities.
By default, the tab shows all console utilities running in the WD - Default workload, at a medium priority.
Instead of using the defaults, you can use the drop down menus on Console Utilities tab to specify different workload priority levels (performance groups) to the individual console utilities listed.
For details on setting console utility priorities, see Teradata Viewpoint User Guide.
Teradata Data Warehouse Appliance 2700 Implementation Guide 253
Chapter 13: Managing the Database
Managing Blocks That Result from Throttle Delays
Managing Blocks That Result from Throttle
Delays
Queries subject to throttles that are also part of a multi-request transaction (multiple requests embedded between BT/ET), may hold resources while in a throttle delay queue. This occurs if earlier requests in the multi-request transaction obtain locks, which will not be released until the entire transaction completes (including the delayed portion).
Delay queue blocks can present a problem because when all currently executing requests for a throttle definition are held in the delay queue, they cannot complete and the block cannot be released.
Teradata IWM detects all delay queue blocks. Sometimes the blocks can resolve themselves over time, but for delay queue blocks that persist, Teradata IWM provides optional attribute settings that you can use to specify how the system manages the blocks.
About the Allowable Delay Queue Blocking Period
Two parameters found on the Workload Designer General settings tab control the duration of the delay queue blocking period.
•
The Exception Interval attribute defines how often the system checks exception thresholds.
If this attribute is set to off, the system takes no block action, regardless of other settings.
The default is 60 seconds.
•
The Block Cycles attribute defines how many Exception Intervals the system waits before taking the action specified in the Block Action attribute. The default setting is 1.
About System Management of the Delay Queue Blocks
The Block Action attribute found on the Workload Designer General settings tab defines what action the system is to take after the defined number of Block Cycles have elapsed. The valid actions are:
•
Log: The request remains in the delay queue (unless system activity has dropped below the throttle threshold) and the system logs the block event to the TDWMEventLog.
•
Abort: Aborts the queued request and then logs the event.
•
Release: Releases the request to freely execute and then logs the event.
The default action is Release.
Configuring Delay Queue Block-Handling Attributes
3
4
1
2
In the General view for a ruleset, click on the Intervals tab.
Set the Exception Interval in seconds. Teradata recommends that you use the default (60).
Click on the Blocker tab.
Set the Block Cycles attribute, for example, to 2. This means the system waits two 60second intervals for the block to resolve before it takes action. Two 60-second cycles is
254 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Monitoring Workloads
5
often enough time for system activity to drop below the throttle threshold and lift the block. If not, the system takes the specified Block Action.
Set the Block Action attribute. Teradata recommends that you try the Release setting.
Although releasing the query is contrary to the threshold rules for queries that would otherwise remain in the delay queue, it still allows for some concurrency management while causing minimal disruption to query execution. You can use another setting if needed.
Monitoring Workloads
Teradata IWM accumulates a variety of data about each workload, at the interval specified on the Workload Monitor portlet dashboard.
Working with Monitoring Intervals
The system uses workload summary data gathered at the intervals specified on the Intervals tab of the Workload Designer General view to generate various displays shown on the
Viewpoint Workload Health and Workload Monitor portlets.
Note: Teradata recommends that you use the default interval settings unless you have a reason to do otherwise.
Interval
Event Interval
Description
The interval of time in seconds between system checks for occurrences of workload-related events logged by the system in the TDWMEventLog.
Default value: 60 seconds
Dashboard Interval The interval over which the system collects workload various data for display on the Workload Monitor portlet. Data is stored in the TDWMSummaryLog, based on Logging interval.
Default value: 60 seconds (which synchronizes with the default refresh time of the Workload Monitor portlet)
Logging Interval Determines the interval at which the system writes logged, workload-related information to log tables and then flushes the information from memory.
Default value: 600 seconds
This interval applies to the following logs:
•
TDWMEventLog
•
TDWMEventHistoryLog
•
TDWMSummaryLog
•
DBQLLogTbl
The value for this interval should be an even multiple of other interval settings.
Teradata Data Warehouse Appliance 2700 Implementation Guide 255
Chapter 13: Managing the Database
Monitoring Workloads
Interval
Exception Interval
Description
The interval of time between system checks for exceptions, if exceptions ar configured.
Default value: 60 seconds
Related Information
Information on...
interval options and how to set them the log tables controlled b the Dashboard interval
Is available in...
Teradata Viewpoint User Guide
Data Dictionary
Using Viewpoint Workload Monitor Portlet
Allows you to monitor workload management activity in the database.
•
Multiple views of workloads and related data.
•
Allocation of system resources per workload
•
Information about the queries being processed, delayed, and rejected
•
Information about individual active queries
Using Data from the TDWMSummaryLog Table
At each Logging interval (See “Working with Monitoring Intervals” on page 255
), the system writes the summarized details, by workload (WD) to the DBC.TDWMSummaryLog table.
Available data include:
•
Arrival count
•
Response time (avg/min/max)
•
CPU time (avg/min/max)
•
Query counts:
•
Active (concurrent)
•
Completed
•
Failed due to error
•
Rejected
•
Delayed
•
Queries moved into or out of the workload using Change WD function
In addition to populating the Workload Monitor portlet, you can use the data in this table to create custom analysis and reports, including use of historical data.
256 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 13: Managing the Database
Checkpoint
Overriding Workload Management Effects for Queries and Sessions
When monitoring workload activity, you may identify queries for which the assigned workload management criteria are not having the needed effect. You can manually manage individual queries from the Query Monitor portlet to improve performance and balance resource usage.
Option
Aborting a query or session
Changing the workload of a query or session
Releasing a Query
Description
You can abort a query or session that is blocking other queries or consuming too many resources
You can change the workload of a query or session to allow higher priority workloads to run or to balance workload resources.
You can release a query from the delay queue for immediate processing.
For information on use of workload management override functions, see
Teradata Viewpoint
User Guide
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.
You can monitor and manage database space.
“Compressing Data to Save Space” on page 223
“Identifying and Correcting Space
You can monitor and manage database queries.
“Managing Query Problems” on page 232
You understand how to create and use accounts.
.
You understand Teradata IWM capabilities and have implemented needed workload controls.
“Setting Up Workload Management” on page 239
If you do not have a result, review and redo the procedure shown in the Reference column.
Teradata Data Warehouse Appliance 2700 Implementation Guide 257
Chapter 13: Managing the Database
Checkpoint
258 Teradata Data Warehouse Appliance 2700 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 2700 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 2700 Implementation Guide 259
Chapter 14: Maintaining the Database
Teradata Database Console Utilities
Reference Information
Information on...
utility functions, syntax, options,
Is available in...
•
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 2700 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 prompt.
cnsterm at the control node command
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
260 Teradata Data Warehouse Appliance 2700 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...
CNS permissions and the CNS GRANT command
Is available in...
“Database Window” in Utilities: Volume 1 (A-K)
5
6
7
8
2
3
4
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
Workstation for Use with SMWeb” on page 47 , navigate to the SMWeb Home page by
following the procedure described in
“Accessing the SMWeb Home Page” on page 48
.
Select Server Management Client.
Log in as a Service User.
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 2700 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 23 .
In the Connect dialog box, click Secure Shell (SSH). Click OK.
In the New Connection dialog box, click the SSH/SFTP tab, and for the Default Username enter root.
Click OK.
At the command prompt, log in as root, a member of the tdtrusted group, or a user with
CNC privileges.
Teradata Data Warehouse Appliance 2700 Implementation Guide 261
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:
2
3
4
5
tdatcmd
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.
At the prompt, start a utility. Preface the utility name with the CNS
start command.
For example:
>start vprocmanager
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.
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
, 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.
262 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Database Maintenance Tasks
1
2
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:
Open a Teradata Command Prompt. See “Logging on to the Control Node” on page 261
At the Linux command prompt of the control node, enter:
3
cnscim -screens 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 line environment.
tdatcmd
to set up the Teradata Database command
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 2700 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 264
•
“Verifying Data Block Integrity” on page 267
•
Additional maintenance tasks that only need to be performed occasionally
Teradata Data Warehouse Appliance 2700 Implementation Guide 263
Chapter 14: Maintaining the Database
Managing Accumulated Log Data
•
“Restarting the Teradata Database Software” on page 269
•
“Upgrading Teradata Software” on page 272
•
“Powering the System Off and On” on page 273
•
“Servicing Unplanned Power Outages” on page 285
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
Access Log
(DBC.AccLogTbl)
Description
Logs that can be purged manually or using Teradata Viewpoint. See
Teradata Viewpoint” on page 265 .
Data collected as defined in a BEGIN LOGGING statement, for each privilege check of an attempted user access of a database object.
Data collected during database query logging (DBQL), if DBQL is enabled.
DBQ Logs:
•
DBC.DBQLSummaryTbl
•
DBC.DBQLStepTbl
•
DBC.DBQLogTbl
•
DBC.DBQLObjTbl
•
DBC.DBQLExplainTbl
•
DBC.DBQLSqlTbl
Data collected automatically by the system for each user logon event.
Event Log
(DBC.EventLog)
ResUsage Logs:
•
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)
ResUsage tables collect data on system resource usage.
You can enable ResUsage data collection and set the collection rate using either:
•
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.
264 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Managing Accumulated Log Data
Logs
TDWM Logs:
•
DBC.TDWMSummaryLog
•
DBC.TDWMEventLog
•
DBC.TDWMExceptionLog
Description
Logs for Teradata Viewpoint workload management functions.
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...
configuring access logging configuration and use of DBQL using the ctl utility SCREEN RSS command to set up ResUsage logging and log intervals setting up Teradata Viewpoint data collectors
Is available in...
Chapter 11: “Monitoring Database Access”
Chapter 14: “Tracking Processing Behavior with
DBQL,” in Database Administration the SCREENRSS command in Chapter 8: “Control
GDO Editor (ctl), in Utilities Volume 1.
“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
2
From the Teradata Viewpoint main screen, select Admin > Teradata System.
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 2700 Implementation Guide 265
Chapter 14: Maintaining the Database
Managing Accumulated Log Data
a b c d
From the SETUP column, select Clean Up Schedule.
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.
Check the Enabled box.
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
2
3
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.
Log on to SQL Administrator as DBADMIN or another administrative user with DELETE privileges on database DBC.
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 ; where:
Syntax Element
object_name
Date
Description
The name of the DBC object that allows log deletions, as shown in “About
. For example, DeleteAccessLogV is the delete object for the Access Log.
SQL syntax element for the current date.
266 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Verifying Data Block Integrity
Syntax Element
LogDate
Description
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
1
2
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
Permission Requirements” on page 260 .
3
Log on to the control node as shown in “Logging on to the Control Node” on page 261
.
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.
Set the priority level under which SCANDISK will execute. For example, on the Database
Console command line, enter: set priority=low
Disable script mode to enable the inquire and abort commands. On the Database Console command line, enter:
4
disable script mode
Start SCANDISK with the following command on the Database Console command line: scandisk
Teradata Data Warehouse Appliance 2700 Implementation Guide 267
Chapter 14: Maintaining the Database
Verifying Data Block Integrity
5
6
7
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.
•
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
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
Teradata @ Your Service” on page 68
.
Running CheckTable at Level 2 for Database DBC
1
2
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
Permission Requirements” on page 260 .
Log on to the control node as shown in “Logging on to the Control Node” on page 261
On the Database Console command line, type:
.
3
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.
When CheckTable has finished checking, it presents a summary of the results, similar to:
156 table(s) checked.
156 fallback table(s) checked.
0 non-fallback table(s) checked.
15 table(s) bypassed due to being unhashed.
0 table(s) failed the check.
0 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;
268 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Restarting the Teradata Database Software
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.
2
3
0 table(s) failed the check.
0 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.
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
Teradata @ Your Service” on page 68
.
Reference Information
Information on...
the CheckTable utility the SCANDISK command
Is available in...
“Checktable” in Utilities: Volume 1 (A-K)
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
Manual
Automatic
Possible Reasons
•
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
•
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
Teradata Data Warehouse Appliance 2700 Implementation Guide 269
Chapter 14: Maintaining the Database
Restarting the Teradata Database Software
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
Maintenance Window” on page 65
.
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
2
Log on to the control node of the system, as described in “Logging on to the Control
At the command line, enter: psh pdestate -a
3
4
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.
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).
To monitor the restart process as it goes through the various stages, run pdestate
periodically, as described in step 2 .
270 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Restarting the Teradata Database Software
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 271 .
Reference Information
Information on...
the tpareset command
Is available in...
“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 271
. If system vprocs or nodes remain down or offline, submit an incident to Customer Support using the Teradata @ Your Service web site,
as described in “Opening an Incident” on page 67 .
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
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
From Viewpoint” on page 259 , start the Vproc Manager utility (vprocmanager) by
entering:
2
start vprocmanager
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
Teradata Data Warehouse Appliance 2700 Implementation Guide 271
Chapter 14: Maintaining the Database
Upgrading Teradata Software
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
--------------------------------------------------------------------------------
3
4
DBS State: Logons are enabled - The system is quiescent
DBS RestartKind: COLD
All PDE nodes are fully online.
Exit Vproc Manager by entering
quit on the Vproc Manager command line.
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 web site, as described in
“Opening an Incident” on page 67
.
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.
Interval
Weekly
Monthly
Quarterly
Items to Review at Teradata @ Your Service
Tech Alerts and associated software patches
Teradata Tools and Utilities client application patches and updates, as described in
Chapter 4: “Setting Up Teradata Clients”
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
Teradata Database Upgrade Guide, Overview, and Preparation
Upgrading Teradata Software (Maintenance): Linux SLES9 SP3, SLES10 SP1,
TD 6.2, 12.0, 13.0
Publication Number
B035-5921-049K
B035-5920-049K
272 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
Publication Title
Parallel Upgrade Tool (PUT) for UNIX MP-RAS and Linux User Guide,
Release 3.04.06
Publication Number
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
2
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.
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.
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.
3 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.
Access the database control node. See “Logging on to the Control Node” on page 261 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 273
Chapter 14: Maintaining the Database
Powering the System Off and On
4
5
6
7
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.
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.
From Server Management Client, verify that the operational states of the chassis in the cabinet or system have an OK status.
a
In the Tree View, select System, then select the View > Status command. The Status window displays.
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.
274 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
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.
Figure 17: Power button with LED and Status LED on VMS Control Panel (Intel R1208 Chassis)
Status LED Power Button with LED
Node 0288
11
At the front of each processing/storage cabinet that has chassis powered off, 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 that has been powered off, use both power switches to power off each drive enclosure.
Caution:
Drive enclosures may contain a controller or an ESM. Ensure the controller is powered off
before the ESM by switching off from the bottom chassis to top in each drive enclosure.
Teradata Data Warehouse Appliance 2700 Implementation Guide 275
Chapter 14: Maintaining the Database
Powering the System Off and On
Figure 18: Power Switches on Drive Enclosure
Rear
Power Switches
Array_0082
13
At the rear of each processing/storage cabinet that has chassis powered off, switch off all of the circuit breakers on each AC feeder box.
Figure 19: Circuit Breaker Switches on 30A Phase-to-Phase and 30A Three-Phase Delta AC Feeder Boxes
276
Power_0089
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
Figure 20: Circuit Breaker Switches on 60A Three-Phase Delta and 30A Three-Phase WYE 230V L-N AC
Feeder Boxes
Power_0090
Note: Switching the circuit breakers off removes power from all chassis and powers down the Ethernet and BYNET InfiniBand switches and KVM.
14
For each BYNET V5 cabinet:
a
Remove the filler panel covering the AC boxes.
b
Switch off all of the circuit breakers on each orange and blue AC box.
Teradata Data Warehouse Appliance 2700 Implementation Guide 277
Chapter 14: Maintaining the Database
Powering the System Off and On
Note: 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.
Figure 21: Circuit Breaker Switches on Blue and Orange AC Boxes
2A
1A
2A
1A
Top 4
Btm. 4
Top 4
Btm. 4
Power_0101
15
For each Platform Framework Cabinet (if present):
a
Remove the filler panel covering the AC boxes.
b
Switch off all of the circuit breakers on each orange and blue AC box.
Note: 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.
16
At the front of each processing cabinet/storage cabinet/Platform Framework cabinet/
BYNET V5 cabinet that has been powered off, verify that all LEDs are off for the following
(depending on your system configuration):
•
Processing nodes
•
Servers
•
Switches
•
Controllers
•
Drive enclosures
•
VMSs
•
Physical SWS
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
The following procedure assumes that the system has been powered off with the Functions >
Power Off command and that the Teradata database has been stopped or nodes have been brought out of the configuration.
Note: When you are ready to restart the database, you may contact Global Technical Services
(GTS) for assistance.
278 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
Top 4
Btm. 4
1
2 a b
At the front of each Platform Framework Cabinet that has been powered off:
a
Switch on all the circuit breakers on each orange and blue AC box.
b
Replace the filler panel for the AC boxes.
At the front of each BYNET V5 cabinet that has been powered off:
Switch on all the circuit breakers on each orange and blue AC box.
Replace the filler panel for the AC boxes.
Figure 22: Circuit Breaker Switches on Blue and Orange AC Boxes
2A
1A
2A
Top 4
Btm. 4
1A
Power_0101
3
At the rear of each processing/storage cabinet that has been powered off, switch on all the circuit breakers on each AC feeder box.
Figure 23: Circuit Breaker Switches on 30A Phase-to-Phase and 30A Three-Phase Delta AC Feeder Boxes
Teradata Data Warehouse Appliance 2700 Implementation Guide
Power_0089
279
Chapter 14: Maintaining the Database
Powering the System Off and On
Figure 24: Circuit Breaker Switches on 60A Three-Phase Delta and 30A Three-Phase WYE 230V L-N AC
Feeder Boxes
280
Power_0090
When the circuit breakers are switched on, the following power on automatically
(depending on your system configuration):
•
VMSs and their hosted VMs (CMIC, Viewpoint, and SWS)
•
Physical SWS
•
KVM
Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
4
5
•
Switches
Note: 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.
If the SWS is not already powered on, manually power up the SWS chassis.
At the rear of each processing/storage cabinet that has been powered off, use both power switches to power on each drive enclosure.
Note: Drive enclosures may contain a controller or an ESM.
a
If present, power on ESMs first, and allow two minutes for them to boot up.
b
Power on the controllers.
It takes approximately three minutes for the drive enclosures to power on completely.
Figure 25: Power Switches on Drive Enclosure
Rear
6
Power Switches
Array_0082
Allow enough time for the CMICs to establish communication with the chassis and then from Server Management Client 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 chassis 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 web site, as described in
“Opening an Incident” on page 67
.
7
Use SYMplicity to place the disk arrays online.
a
From the SWS, open SYMplicity.
Teradata Data Warehouse Appliance 2700 Implementation Guide 281
Chapter 14: Maintaining the Database
Powering the System Off and On
b c
In the Enterprise Management window, select the Devices tab.
Double click the array where the offline controller is located (indicated by a red circle with a down pointing arrow).
f g h d e
In the Array Management window, select the Physical tab.
Click the offline controller (indicated by a red circle with an "x").
Select Advanced > Recovery > Place Controller > Online.
When a confirmation dialog box appears, click Yes.
Allow approximately 3 minutes for the controller to come online.
When the controller is online, the seven segment display will show the tray ID.
Caution:
If the correct number of drive enclosures are not displayed, or their icons are not green, submit an incident through Teradata @ Your Service.
8
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.
9 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 and servers (if present) to boot and to allow enough time for the CMICs to establish communication with all node and server chassis.
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.
10
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.
282 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Powering the System Off and On
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.
11 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 23 .
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 2700 Implementation Guide system with two nodes on the BYNET over Ethernet, the following message should display:
Net #
0
1
Nodes
2
2
Routes
2
2
Net name eth2 eth3
•
For a Teradata Data Warehouse Appliance 2700 Implementation Guide system with four nodes on the BYNET V5 over InfiniBand, the following message should display:
Net #
0
1
Nodes
4
4
Routes
4
4
Net name
mlx4_0_1 mlx4_0_2
Where:
•
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 2700 Implementation Guide system
•
Routes is the current number of network routing paths (usually one routing path per node)
•
Net name is the network interface name
Teradata Data Warehouse Appliance 2700 Implementation Guide 283
Chapter 14: Maintaining the Database
Powering the System Off and On
g i
Verify that all the pdisks on all the nodes are good.
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
j a
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.
12
Use vprocmanager to verify that all vprocs have started.
At the Teradata command prompt, type the following and press
tdatcmd
Enter
:
b
At the Teradata command prompt, type the following and press
vprocmanager
Enter
:
c
At the vprocmanager command prompt, type the following and press
status notonline
Enter
:
d
In the output, verify that the following message displays:
All DBS vprocs are fully online
All PDE nodes are fully online
If the messages do 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 271
.
284 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 14: Maintaining the Database
Servicing Unplanned Power Outages
Servicing Unplanned Power Outages
In the event of an unplanned power outage:
•
Submit an incident to Customer Support using the Teradata @ Your Service web site, as
described in “Opening an Incident” on page 67 .
•
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 278 .
Checkpoint
Before leaving this chapter, make sure that:
Result
You know the various methods for running console utilities.
You have a procedure for regularly purging accumulated log data.
You regularly check for data corruption in the database and file system.
You know how to restart Teradata Database software.
You know when to upgrade Teradata software and how to request assistance from Teradata
Customer Service.
You know how to stop the database and shut down the system hardware. You also know how to restore power and restart the database.
You know what to do in the event of an unplanned system outage.
Reference
“Running Database Utilities From
.
“Managing Accumulated Log Data” on page 264
.
“Verifying Data Block Integrity” on page 267
.
“Restarting the Teradata Database
.
“Upgrading Teradata Software” on page 272
.
“Powering the System Off and On” on page 273
.
“Servicing Unplanned Power Outages” on page 285 .
If you do not have these results, return to the section in the Reference column and review that procedure.
Teradata Data Warehouse Appliance 2700 Implementation Guide 285
Chapter 14: Maintaining the Database
Checkpoint
286 Teradata Data Warehouse Appliance 2700 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 291
.
•
“Loading a Data From an External ODBC Database” on page 292
.
•
“Loading Data from an External Flat File” on page 297
.
•
“Exporting Data to an External Flat File” on page 301
.
•
“Launching a Teradata PT Job” on page 304
.
•
“Monitoring and Managing a Teradata PT Job” on page 305
.
•
“Evaluating a Completed Teradata PT Job” on page 306
.
•
“Troubleshooting a Failed Job” on page 307
.
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 2700 Implementation Guide 287
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
DEFINE JOB job_name
APPLY dml
TO OPERATOR
($
consumer_operator_name)
SELECT * FROM OPERATOR
($
producer_operator_name)
Description
The name of the job. Use a descriptive name, for example,
Load_Daily_Transactions.
The operation to perform on the target, for example, $INSERT.
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
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
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
288 Teradata Data Warehouse Appliance 2700 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
Local 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 290
.
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 293
.
To use a local job variables file, specify the file name when launching the job. See
“Launching a Teradata PT Job” on page 304 .
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 304 .
Teradata Data Warehouse Appliance 2700 Implementation Guide 289
Chapter 15: Moving Data To and From Teradata Database Tables
About TPT Configuration Files
Related Information
For information about...
scripting options beyond the easy scripting examples shown in this chapter operators, including required
See...
Teradata Parallel Transporter User Guide
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
Checkpoint directory
Logs directory
Contains global variable values that can be used by many jobs.
See Using Global Job Variables .
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.
•
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
Operators that read from Teradata
Database, for example:
•
Export operator
Job Variable Name
SourceTdpId
SourceUserName
SourceUserPassword
SourceAccountId
Description
The name of the Teradata Database system from which the operator exports, for example,
TDATSys1.
The name and password for a Teradata Database user with SELECT privileges on tables accessed by
TPT jobs.
The account assigned to the SourceUser. A portion of the account string prioritizes the job.
290 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Using Global Job Variables
Affected Operators
Operators that write to Teradata Database, for example:
•
Load operator
•
Update operator
Job Variable Name
TargetTdpId
TargetUserName
TargetUserPassword
TargetAccountId
Operators that read from an external
ODBC-compliant database, for example:
•
ODBC operator
ODBCDSNname
ODBCUserName
ODBCUserPassword
Description
The name of the Teradata system to which the operator loads data, for example, TdatSys1.
The name and password for a Teradata Database user with INSERT/UPDATE?DELETE privileges on tables accessed by TPT jobs.
The account assigned to the TargetUser. A portion of the account string prioritizes the job
The name used to identify the ODBC data source
in “Setting Up an External ODBC Data Source” on page 81
.
The name and password for a valid user of the
ODBC data source, having SELECT privileges on tables accessed by TPT jobs.
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
4
5
2
3
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
Open the twbcfg file. Notice that the Checkpoint and Logs directories already exist.
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.
Create the GlobalJobVariables directory in the specified location.
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 = 'tdpid'
,SourceUserName = 'tdusername'
,SourceUserPassword = 'tdpassword'
,SourceUserAccountId = 'account_id'
,TargetTdpId = 'tdpid'
,TargetUserName = 'tdusername'
Teradata Data Warehouse Appliance 2700 Implementation Guide 291
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
,TargetUserPassword = 'tdpassword'
,TargetUserAccountId = 'account_id'
,ODBCDSNname = 'odbc_dsnname'
,ODBCUserName = 'odbc_username'
,ODBCUserPassword = 'odbc_password'
d
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
Load
Operator
Write
Data
Teradata
Database
Producer
Operator
Consumer
Operator
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 81 .
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 113 .
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);
);
292 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
2
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.
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
TargetTable
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 l ocal job variables file if you want to override the global values.
See “Setting Up the Global Job Variables File” on page 291
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.
The name of the Teradata Database table being loaded.
Teradata Data Warehouse Appliance 2700 Implementation Guide 293
Chapter 15: Moving Data To and From Teradata Database Tables
Loading a Data From an External ODBC Database
Load Operator
Job Variable Name
ErrorTable1
ErrorTable2
LogTable
LoadPrivateLogName
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.
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.
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.
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.
2
For additional information and usage notes for Load operator attributes, see the chapter on Load operator in Teradata Parallel Transporter Reference.
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:
294 Teradata Data Warehouse Appliance 2700 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
ODBCDSNname
Job Variable Value
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.
The password for the user specified by UserName.
ODBCUserPassword
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 296
.
3
4
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 = 'tdpId'
,TargetUserName = 'tdusername'
,TargetUserPassword = 'tdpassword'
,TargetAccountId = 'account_id'
,TargetWorkingDatabase= 'database_name'
,LoadPrivateLogName = 'loadlog'
,TargetTable = 'target_table_name'
,ErrorTable1 = 'jobname_E1'
,ErrorTable2 = 'jobname_E2'
,LogTable = 'jobname_logtable'
,ODBCDSNname = 'DSNname'
,ODBCPrivateLogName = 'odbclog'
,ODBCUserName = 'odbcusername'
,ODBCUserPassword = 'odbcpassword'
,ODBCTruncateData = 'No'
,ODBCSelectStmt = '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.
Save the job variables file as job_nameVar.txt, to the directory that contains the job script.
Teradata Data Warehouse Appliance 2700 Implementation Guide 295
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 304 .
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 non-
Teradata Databases (for example, Oracle) and moving it to Teradata Database, you may encounter varying results depending on several data factors:
•
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.
•
For source column NUMBER (m, n) and target column DECIMAL (M, N), the job does the following:
296 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Loading Data from an External Flat File
•
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
Load
Operator
Write
Data
Teradata
Database
Producer
Operator
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 81 .
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.
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);
Teradata Data Warehouse Appliance 2700 Implementation Guide 297
Chapter 15: Moving Data To and From Teradata Database Tables
Loading Data from an External Flat File
2
);
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.
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
TargetTable
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 l ocal job variables file if you want to change values.
See “Setting Up the Global Job Variables File” on page 291
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.
The name of the Teradata Database table being loaded.
298 Teradata Data Warehouse Appliance 2700 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
ErrorTable2
LogTable
LoadPrivateLogName
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.
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.
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.
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 2700 Implementation Guide 299
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
SourceFileName
Job Variable Value
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 The access mode ('read' or 'write'). The value for $File_Reader is 'read'.
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:
TargetTdpId = 'tdpId'
,TargetUserName = 'tdusername'
,TargetUserPassword = 'tdpassword'
,TargetAccountId = 'account_id'
,TargetWorkingDatabase= 'database_name'
,LoadPrivateLogName = 'loadlog'
,TargetTable = 'target_table_name'
,ErrorTable1 = 'jobname_E1'
,ErrorTable2 = 'jobname_E2'
,LogTable = 'jobname_logtable'
,SourceFileName = 'flatfile_name'
,SourceFormat = 'delimited'
,SourceTextDelimiter = '|'
,OpenMode = 'read'
300 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Exporting Data to an External Flat File
4
Note: Operator job variable names are shown in the order the operators appear in the job script, but this arrangement is not required.
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 304 .
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
Export
Operator
Read
Data
Teradata
Database
Consumer
Operator
Producer
Operator
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:
2
DEFINE JOB job_name
(
APPLY $INSERT TO OPERATOR ($FILE_WRITER)
SELECT * FROM OPERATOR($EXPORT);
);
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 2700 Implementation Guide 301
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
TargetFileName
Job Variable Value
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 The access mode ('read' or 'write'). The value for $File_Writer is 'write'.
2
Identify the $EXPORT operator attributes you want to use and assign values to the corresponding job variable names. Commonly used $EXPORT operator attributes are:
302 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Exporting Data to an External Flat File
Export Operator
Job Variable Name
SourceTdpId
SourceUserName
SourceUserPassword
SourceAccountId
ExportPrivateLogName
SelectStmt
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 l ocal job variables file if you want to change values.
See “Setting Up the Global Job Variables File” on page 291
for specification instructions.
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.
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
4
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 = 'flatfile_name'
,TargetFormat = 'delimited'
,TargetTextDelimiter = '|'
,OpenMode = 'write'
,SourceTdpId = 'tdpId'
,SourceUserName = 'tdusername'
,SourceUserPassword = 'tdpassword'
,SourceAccountId = 'account_id'
,ExportPrivateLogName = 'exportlog'
,SourceTable = 'databasename.tablename'
,LogTable = 'jobname_restart'
,SelectStmt = '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
Teradata Data Warehouse Appliance 2700 Implementation Guide 303
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
2
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
Enter the following at the command prompt: tbuild -f filename -v job_variables_filename -j jobname where:
Option or Parameter
-f filename
-v
job_variables_filename
-j jobname
Specifies
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.
The job variables file associated with the job script. See
“Defining the Local Job Variables” on page 293 .
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.
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 306 .
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
Reference Information
Information on...
tbuild syntax and options
Is available in...
Teradata Parallel Transporter Reference
304 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Monitoring and Managing a Teradata PT Job
Information on...
using tbuild
Is available in...
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:
2
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.
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...
twbcmd syntax and options using twbcmd
Is available in...
Teradata Parallel Transporter Reference
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 where job_id is the job name followed by a dash (“-”) and the job sequence number generated by the system at launch.
Teradata Data Warehouse Appliance 2700 Implementation Guide 305
Chapter 15: Moving Data To and From Teradata Database Tables
Evaluating a Completed Teradata PT Job
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:
2
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.
When the job terminates, check the logs, as shown in
“Troubleshooting a Failed Job” on page 307 , to determine the cause of the job termination.
Reference Information
Information on...
the twbkill command
Is available in...
•
“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.
4
8
Exit Code
0
12
Description.
Completed successfully.
Completed successfully, but issued one or more warnings.
Terminated due to a user error, such as a syntax error.
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.
•
If the exit code is 0, the job was successful and no further action is required.
•
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.
306 Teradata Data Warehouse Appliance 2700 Implementation Guide
Chapter 15: Moving Data To and From Teradata Database Tables
Troubleshooting a Failed Job
3
•
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 307
.
Reference Information
Information on...
exit codes, error tables, logs, and strategies for evaluating a job
Is available in...
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
Access the logs and error tables for the job.
2
•
The Public Log is located in the Logs directory. See “About TPT Configuration Files” on page 290
.
•
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.
3
•
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.
Once the causes of errors have been corrected in the job script, you can re-launch the job.
Teradata Data Warehouse Appliance 2700 Implementation Guide 307
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
The Global Job Variables file is set up and ready for use.
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.
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.
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.
You have successfully launched a TPT job and monitored it as it ran.
You have used the TPT error code system to evaluate a completed job.
You understand how to examine the logs and error files to determine the cause and corrective action for a failed job.
Reference
“Setting Up the Global Job Variables
“Loading a Data From an External
“Loading Data from an External Flat
“Exporting Data to an External Flat
“Launching a Teradata PT Job” on page 304
“Evaluating a Completed Teradata PT
“Troubleshooting a Failed Job” on page 307
If you do not have these results, return to the section in the Reference column and review that procedure.
308 Teradata Data Warehouse Appliance 2700 Implementation Guide
APPENDIX A
Type and Format Differences
Between Teradata and Other DBMS
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 to be 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
BINARY_DOUBLE
BINARY_FLOAT
BLOB/CLOB
CHAR
DATE
FLOAT
LONG
LONG RAW
NUMBER or NUMBER (*)
NUMBER(38)
NUMBER(n, m)
VARCHAR2
Teradata Data Type
FLOAT
FLOAT
BLOB/CLOB
CHAR
DATE or TIMESTAMP(0)
NUMBER
LONG VARCHAR or VARCHAR
VARBYTE (<=64000)
NUMBER or NUMBER (*)
NUMBER(38)
NUMBER(n, m)
VARCHAR
Teradata Data Warehouse Appliance 2700 Implementation Guide 309
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
0 (IntegerDate, the default)
1 (ANSIDate)
Description
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.
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 DBSControl in Utilities: Volume 1 (A-K).
310 Teradata Data Warehouse Appliance 2700 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 ...
the system the session a user a DATE column or DATE value
Use the ...
•
DBS Control utility to change the DateForm setting.
•
Locale Definition utility (tdlocaledef) to customize the SDF file.
SET SESSION DATEFORM statement.
DATEFORM option in the CREATE USER or
MODIFY USER statement.
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.
Distinct Types
Distinct UDTs are based on a single predefined data type, such as INTEGER or VARCHAR.
Teradata Data Warehouse Appliance 2700 Implementation Guide 311
Appendix A: Type and Format Differences Between Teradata and Other DBMS
Reference Information
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...
supported data types in Teradata Database, including UDTs
DATE literals
DATE formats and the FORMAT phrase using the DBS Control utility (dbscontrol) to change the DateForm setting the SDF file and the Locale Definition utility (tdlocaledef)
•
CREATE USER / MODIFY USER
•
HELP SESSION
•
SET SESSION DATEFORM
Is available in...
SQL Data Types and Literals
SQL Data Types and Literals
Utilities: Volume 1 (A-K)
Utilities: Volume 2 (L-Z)
SQL Data Definition Language Detailed Topics
312 Teradata Data Warehouse Appliance 2700 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
Consumes less client CPU.
Loads or updates either all records or stops after x records that you specify with the REPEAT command.
Limited error handling.
Teradata PT
Consumes more client CPU.
Can also load or update only selected rows.
No checkpoint restart.
No SERIALIZE option.
Does not process multiple DML statements in a single pass of the input data.
Performs error handling and creates error log tables.
Checkpoint restart.
SERIALIZE option ensures the correct sequencing of transactions.
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 2700 Implementation Guide 313
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...
BTEQ commands, including
PACK running batch jobs to submit
BTEQ commands and
Teradata SQL
Is available in...
Basic Teradata Query Reference
•
“Using BTEQ Scripts to Create Database Objects” on page 129
•
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;
314 Teradata Data Warehouse Appliance 2700 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 2700 Implementation Guide 315
Appendix B: Loading and Updating Tables with BTEQ
Updating Tables
316 Teradata Data Warehouse Appliance 2700 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 154
.
Differences Between Macros and Procedures
Macros and procedures provide similar benefits. The following table provides a comparison between macros and procedures.
Macros Procedures
Support limited procedural logic Support sophisticated logic
Provide easy execution of simple, repetitive SQL Provide 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
Can reduce network traffic in the client-server environment (procedures reside and execute on the server)
Teradata Data Warehouse Appliance 2700 Implementation Guide 317
Appendix C: Advanced Features
About Procedures and External Procedures
Macros Procedures
Provide exception handling features to handle the runtime conditions generated by an application
Reference Information
Information on...
overview of procedures
SQL procedures (procedures that are written using SQL statements) external procedures (procedures that are written using C, C++, or Java) syntax and options for:
•
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
Is available in...
SQL Fundamentals
SQL Stored Procedures and Embedded SQL
SQL External Routine Programming
•
SQL Data Definition Language Syntax and
Examples
•
SQL Data Definition Language Detailed Topics
SQL Data Manipulation Language
318 Teradata Data Warehouse Appliance 2700 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...
implementing and using UDFs syntax and options for:
•
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
Is available in...
SQL External Routine Programming
•
SQL Data Definition Language Syntax and Examples
•
SQL Data Definition Language Detailed Topics
SQL Data Manipulation Language
Teradata Data Warehouse Appliance 2700 Implementation Guide 319
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 web site accesses a particular page to make it easier and faster to produce a monthly report.
Reference Information
Information on...
triggers
Is available in...
•
Introduction to Teradata
•
SQL Fundamentals
320 Teradata Data Warehouse Appliance 2700 Implementation Guide
Scarica
Link pubblico aggiornato
Il link pubblico alla tua chat è stato aggiornato. Puoi visualizzare e gestire i tuoi link di chat dopo la registrazione qui.
Link pubblico del documento
Pubblicità
