Teradata Release 15.00.01 QueryGrid User manual
Διαφήμιση
Διαφήμιση
What would you do if you knew?™
Teradata QueryGrid
Teradata QueryGrid: Teradata Database-to-
Teradata Database
Release 15.00.01
B035-1188-015K
January 2016
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 Marketing Studio, Aster, BYNET, Claraview,
DecisionCast, Gridscale, MyCommerce, QueryGrid, SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, Teradata
ServiceConnect, Teradata Source Experts, 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 Avro, Apache Hadoop, Apache Hive, 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 Dell 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.
SAP is the trademark or registered trademark of SAP AG in Germany and in several other countries.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
Simba, the Simba logo, SimbaEngine, SimbaEngine C/S, SimbaExpress and SimbaLib are registered trademarks of Simba Technologies Inc.
SPARC is a registered trademark of SPARC International, Inc.
Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries.
Unicode is a registered trademark of Unicode, Inc. in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
The information contained in this document is provided on an "as-is" basis, without warranty of any kind, either express or implied, including the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you. In no event will Teradata Corporation be liable for any indirect, direct, special, incidental, or consequential damages, including lost profits or lost savings, even if expressly advised of the possibility of such damages.
The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: [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
©
2015 - 2016 by Teradata. All Rights Reserved.
Preface
Purpose
This book describes the Teradata
®
QueryGrid
™
: Teradata Database-to-Teradata Database
SQL interface for transferring data between Teradata Database and remote Teradata
Database hosts.
Use this book with the other books in the SQL book set.
Audience
This book is intended for database administrators and other technical personnel who use
Teradata Database.
Supported Releases
For Teradata QueryGrid supported releases information, see KAP314E23E .
Prerequisites
You should be familiar with basic relational database management theory and technology.
To become familiar with concepts specific to Teradata Database, read Introduction to
Teradata and SQL Fundamentals.
Changes to This Book
Release
Teradata QueryGrid:
Teradata-to-Teradata
15.00.01
January 2016
Description
• Added information about the new name value pair, disable_pushdown to the Syntax chapter.
• Noted throughout that the name of the efsspop table operator has been changed to efsspop_tdsqlt.
• Clarified that the logon password is encrypted.
• Added the ServerInfoV[X] view to the Data Dictionary chapter.
Teradata QueryGrid: Teradata Database-to-Teradata Database 3
Preface
Additional Information
Release
Teradata QueryGrid:
Teradata-to-Teradata
15.0
January 2015
Description
• Updated the EXPLAIN text for SELECT queries, updated Limitations section.
Initial publication.
Additional Information
URL
www.info.teradata.com
Description
Use the Teradata Information Products Publishing Library site to:
• View or download a manual:
• Under Online Publications, select General Search.
• Enter your search criteria and click Search.
• Download a documentation CD-ROM:
• Under Online Publications, select General Search.
• In the Title or Keyword field, enter CD-ROM, and click Search.
www.teradata.com
The Teradata home page provides links to numerous sources of information about Teradata. Links include:
• Executive reports, white papers, case studies of customer experiences with Teradata, and thought leadership
• Technical information, solutions, and expert advice
• Press releases, mentions and media resources www.teradata.com/TEN/
Teradata Customer Education delivers training that builds skills and capabilities for our customers, enabling them to maximize their
Teradata investment.
https://tays.teradata.com
Use Teradata @ Your Service to access Orange Books, technical alerts, and knowledge repositories, view and join forums, and download software patches.
Teradata Developer
Exchange
Teradata Developer Exchange provides articles on using Teradata products, technical discussion forums, and code downloads.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please email [email protected]
.
4
Product Safety Information
This document may contain information addressing product safety practices related to data or property damage, identified by the word Notice. A notice indicates a situation which, if not
Teradata QueryGrid: Teradata Database-to-Teradata Database
Preface
Product Safety Information avoided, could result in damage to property, such as equipment or data, but not related to personal injury.
Example
Notice:
Improper use of the Reconfiguration utility can result in data loss.
Teradata QueryGrid: Teradata Database-to-Teradata Database 5
Preface
Product Safety Information
6 Teradata QueryGrid: Teradata Database-to-Teradata Database
CHAPTER 1
Introduction to Teradata QueryGrid: Teradata
Database-to-Teradata Database
Overview of Teradata QueryGrid: Teradata
Database-to-Teradata Database
Teradata QueryGrid: Teradata Database-to-Teradata Database (also referred to as the
Teradata-to-Teradata connector) provides an SQL interface for easily accessing data located on a remote Teradata Database system. Using the foreign server grammar that was released to operate with Teradata Database version 15.0, you can use a SQL SELECT query to join local data with the data in tables on a remote Teradata Database.
Note: We define the local system as the system on which the user logs on; the remote system is the system that the user accesses using the foreign server grammar.
The Teradata-to-Teradata connector provides the following routines for database users:
• The LOAD_FROM_TD table operator used to import data from a remote Teradata
Database.
• The LOAD_TO_TD table operator used to export data to a remote Teradata Database.
• The ExecuteForeignSQL stored procedure used to execute a range of SQL queries, such as
CREATE, DROP, DELETE, and GRANT, on a remote Teradata Database.
• The efsspop_tdsqlt table operator, which is needed when you create a foreign server object so that you can use the ExecuteForeignSQL syntax to run SQL queries on the remote Teradata server.
Note: The name of the efsspop table operator has been changed to efsspop_tdsqlt. If you have defined a foreign server to use the legacy efsspop table operator, then to work with
Release 15.0.1 of the connector, you need to redefine the foreign server, or use ALTER
FOREIGN SERVER to change its import operator to efsspop_tdsqlt.
The Teradata-to-Teradata connector also provides the following internal routines at installation:
• The LOAD_FROM_TDREMOTE table operator, which is used internally on the remote
Teradata Database to import the data that is exported from the local system. You do not call this operator directly, but you do need to GRANT EXECUTE FUNCTION and
SELECT privileges on it.
• The LOAD_TO_TDREMOTE table operator, which is used internally on the remote
Teradata Database to export the data back to the local system. You do not call this
Teradata QueryGrid: Teradata Database-to-Teradata Database 7
Chapter 1 Introduction to Teradata QueryGrid: Teradata Database-to-Teradata Database
Overview of Teradata QueryGrid: Teradata Database-to-Teradata Database operator directly, but you do need to GRANT EXECUTE FUNCTION and SELECT privileges on it.
For information about the privileges needed for these routines, see
Benefits
Enables you to access remote Teradata data easily.
The Teradata Database 15.0 foreign server grammar allows the connection information to be managed separately and simplifies the user grammar.
Considerations
You may not use this feature without the appropriate license. The fact that this feature may be included in product media or downloads, or described in documentation that you receive does not authorize you to use it without the appropriate license. Contact your Teradata sales representative to purchase and enable this feature. It installs on one node on each Teradata system.
For Teradata QueryGrid supported releases information, see KAP314E23E .
You should configure a proxy user on one or both of the Teradata Database systems.
Limitations
• Transaction semantics are not supported between the Teradata systems.
• Queue tables are not supported on the remote Teradata system.
• Formats that are defined only in remote tables are not available on the local system.
To work around this limitation, you can do a cast or you can create a view with casts.
• ORDER BY clauses are not supported when you use SELECT with a FOREIGN TABLE.
To work around this limitation, you can order the results after they are returned to the local system.
• In partition tables, the PARTITION system-derived column cannot be selected from a remote table.
• The indirection of remote links is not supported. In the case where a view on the remote is defined with a SELECT * from db.table@otherremote, when the local system does a
SELECT * from view@remote, it is the proxy user who selects the view. When that proxy user attempts to make the connection to otherremote, the connection is made under the proxy name rather than the name of the user on the local system.
• Remote queries execute under the proxy user. You must have adequate space for all users who use a particular FOREIGN SERVER definition. You can create multiple definitions that use different authorizations for the same system if you need to separate space between groups of users.
8 Teradata QueryGrid: Teradata Database-to-Teradata Database
CHAPTER 2
Syntax for Teradata QueryGrid: Teradata
Database-to-Teradata Database
Introduction to Teradata QueryGrid: Teradata
Database-to-Teradata Database Syntax
This section describes the syntax and options for the Teradata-to-Teradata connector, and provides examples of their use. It includes DDL statements, and information about DML and DCL statements.
To use the Teradata-to-Teradata connector effectively, you should understand and partition the data appropriately so that a limited set of data is imported for joining.
If you are a DBA, we recommend that you start by reading Teradata Configuration
. If a DBA has already set up the Teradata systems and has granted you the privileges needed to create foreign servers, we recommend that you start by reading
.
Supported Data Types
The data types supported by the Teradata-to-Teradata connector are as follows:
• CHAR fixed
• VARCHAR
• BYTE
• VARBYTE
• BYTEINT
• SMALLINT
• INTEGER
• BIGINT
• REAL
• DECIMAL
• NUMBER
• DATE
• TIME
• TIMESTAMP
• INTERVAL
• TIME with ZONE
• TIMESTAMP with ZONE
• ARRAY
Teradata QueryGrid: Teradata Database-to-Teradata Database 9
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Introduction to Teradata QueryGrid: Teradata Database-to-Teradata Database Syntax
Note: If used, array must be cast.
Transaction Semantics Limitation
3.
4.
1.
2.
Transaction semantics are not supported between Teradata systems. For example, suppose that the following statements are executed in this order:
BEGIN Transaction ;
INSERT INTO t1@remote SELECT * FROM local
INSERT INTO local values (1,2)
END Transaction ;
If the second statement fails, then the data that is being inserted into table t1 is rolled back if it has not been committed by the local system. Once it is committed by the local system, a late arriving abort does not roll back the data.
If an error occurs on the third statement, the data in the remote system is not rolled back. It is already committed from the remote system’s perspective.
Basis for the Examples Used
Most of the syntax examples are based on the use of the following two Teradata 15.0 systems.
The local Teradata Database system is called local_system, and it contains a single database named store. The store database contains the following tables and columns:
• Item_Master
• item_no INTEGER
• item_desc VARCHAR(20)
• Item_Inventory
• item_no INTEGER
• item_qty INTEGER
The remote Teradata Database system is called remote_system, and it also contains a single database named store. The store database contains the following tables and columns:
• Item_Price
• item_no INTEGER
• item_price DECIMAL(10,2)
• Customer_Order
• order_no INTEGER
• customer_id INTEGER
• item_no INTEGER
• item_qty INTEGER
• orderdate DATE
10 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
ALTER FOREIGN SERVER
ALTER FOREIGN SERVER
Purpose
Modifies the parameters of an existing server object.
Syntax
ALTER FOREIGN SERVER
server_name
EXTERNAL SECURITY INVOKER
DEFINER
A
ADD
DROP
, modify options drop options
TRUSTED
authorization_name
;
A
Syntax Elements
server_name
The name of the foreign server object.
EXTERNAL SECURITY
Associates an authorization object with the foreign server. The authorization stores the encrypted credentials for a user as a database object. The QueryGrid connector passes the
Teradata QueryGrid: Teradata Database-to-Teradata Database 11
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
ALTER FOREIGN SERVER
12 credentials in the authorization to the remote platform identified by the foreign server when the foreign server is accessed.
You must use the TRUSTED security type for Teradata QueryGrid: Teradata Database-to-
Teradata Database.
TRUSTED
A keyword that indicates the associated authorization was created as TRUSTED.
INVOKER
A keyword that indicates that the associated authorization must be present in the user database at the time that the foreign server is accessed.
Note: The user database is the database that was created for the user in the Teradata system when the user account was created.
You can specify either a DEFINER or an INVOKER, but not both. If neither INVOKER nor DEFINER are specified then INVOKER is used by default.
DEFINER
A keyword that indicates that the associated authorization must be present in the database that contains the foreign server when the foreign server is accessed.
You can specify either a DEFINER or an INVOKER, but not both.
Note: The DEFAULT keyword that can be used with DEFINER in CREATE
AUTHORIZATION and REPLACE AUTHORIZATION statements is not needed in association with a foreign server.
authorization_name
Specifies the name of the authorization object to be used when the foreign server is accessed.
Modify options
ADD
You can use to the ADD option to make the following changes:
• add or replace a global name value pair that is used to define the server object
• add an IMPORT or EXPORT table operator. If you want to replace a table operator that is already associated with the foreign server you must first drop the table operator before adding the new one.
name('value')
The name value pair or pairs that you want to add or modify.
IMPORT
Indicates that you are going to act on the operator that is used to import data into
Teradata Database.
EXPORT
Indicates that you are going to act on the operator that is used to export data out of
Teradata Database.
operator_name
The name of the operator that you want to use. Teradata currently provides the following table operators for use with the Teradata-to-Teradata connector:
Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
ALTER FOREIGN SERVER
• LOAD_FROM_TD
• LOAD_TO_TD
The LOAD_FROM_TD operator retrieves data from a remote Teradata Database for use in a local Teradata Database, where the data can be placed in tables or joined with existing tables.
It produces a spooled table that contains the specified data from the remote system. The query that you use can be part of a larger query and can be joined against other Teradata
Database tables and views. The data is imported in parallel from multiple nodes into multiple Teradata Database AMPs.
The LOAD_TO_TD operator exports data from Teradata Database into a remote Teradata
Database, where the data can be placed in tables or joined with existing tables.
Note: The Teradata-to-Teradata connector table operators do not have specific operator options and users cannot call these table operators directly.
name (‘value’ )
The name value parameter pair or pairs that you want to add or the name of the existing parameters with the new values that you want to use. These are global parameters of the server object.
Note: With the exception of the port NVP, do not use surrounding single quotes for name value pairs that are composed of integers. The other NVPs that contain only integers are handled differently from those that contain alphabetic or alphanumeric strings. If you delimit an integer value with single quotes, then the value is silently ignored and the default value is used instead.
For more information about the global name value pairs used with the server object, see
USING Option in CREATE FOREIGN SERVER.
Drop options
DROP
You can use the DROP option to make the following changes:
• drop a global name value pair that was used to define a server object. You need only specify the name to drop the pair.
• drop an IMPORT or EXPORT table operator that was associated with a server definition.
When you drop a table operator, all related name value pairs are also dropped.
name
When used alone, name is the name of the name value pair that you want to drop.
IMPORT
Indicates that you are going to act on the operator that is used to import data into
Teradata Database.
EXPORT
Indicates that you are going to act on the operator that is used to export data out of
Teradata Database
Required Privileges
You must have DROP SERVER privilege on the TD_SERVER_DB database or on the specified foreign server to modify the foreign server object. If you are modifying the table
Teradata QueryGrid: Teradata Database-to-Teradata Database 13
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
BEGIN LOGGING operators that are associated with the server, or adding a table operator, you must also have
EXECUTE FUNCTION and SELECT privileges on the specified table operators.
Usage Notes
You cannot use the following names in the name value pairs in ALTER SERVER statements:
• Columns
• hExplain
• IsNested
• Servermode
• If EXTERNAL SECURITY TRUSTED is specified, then you must also avoid the use of
Proxyusername and Proxypass.
Note: External security options and ADD or DROP clauses must be specified in the syntax.
Example of Using ALTER FOREIGN SERVER Syntax
This example demonstrates altering a foreign server in Teradata Database by changing the number of parallel socket connections between the local Teradata node and the remote
Teradata node.
ALTER FOREIGN SERVER remote_system
ADD concurrentstreams(2) ;
BEGIN LOGGING
Purpose
Starts the auditing of SQL requests that attempt to access data.
This topic describes only the portions of the BEGIN LOGGING syntax diagram that are specific to this Teradata QueryGrid connector. For information about the other syntax that you can use with BEGIN LOGGING, see SQL Data Definition Language - Syntax and
Examples, B035-1144.
14 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
COMMENT (Comment Placing Form)
Syntax
BEGIN LOGGING ON
A
A
DENIALS
FOR CONSTRAINT
WITH TEXT
constraint_name
FIRST
LAST
FIRST AND LAST
EACH
ALL
,
operation
GRANT
BY
,
database_name user_name
B
ON
,
20
AUTHORIZATION authorization_name
DATABASE database_name
USER database_name
TABLE
VIEW
MACRO
PROCEDURE
FUNCTION
TYPE
FOREIGN SERVER
database_name.
user_name.
object_name
;
Syntax Element
ON FOREIGN SERVER object_name
Indicates that the database object for which access is to be logged is a foreign server.
You must specify an object name, which is the name of the foreign server. You can optionally specify the name of the containing database, which must be
TD_SERVER_DB. You cannot use a user_name with FOREIGN SERVER.
B
COMMENT (Comment Placing Form)
Purpose
Creates a user-defined description of a user-defined database object or definition in the data dictionary.
This topic describes only the portions of the COMMENT syntax diagram that are specific to
Teradata QueryGrid. For information about the other syntax elements in COMMENT
(Comment Placing Form), see SQL Data Definition Language - Syntax and Examples,
B035-1144.
Teradata QueryGrid: Teradata Database-to-Teradata Database 15
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE AUTHORIZATION and REPLACE AUTHORIZATION
Syntax
COMMENT
ON
object_kind_1 object_kind_2 database_name.
user_name.
object_name
AS
IS
'comment'
;
Syntax Element
object_kind_2
An optional database object kind specification.
You can specify the following database object kinds to retrieve a comment for the kind of object they represent, but they are optional.
• DATABASE
• FOREIGN SERVER
• TABLE
• USER
If you specify an optional database_name with FOREIGN SERVER, the name must be
TD_SERVER_DB. You cannot use a user_name with FOREIGN SERVER.
All existing rules for COMMENT apply for use with a FOREIGN SERVER object.
The optional comment string is recorded in DBC.TVM.
For more information about using COMMENT (Comment Placing Form), see SQL Data
Definition Language - Syntax and Examples, B035-1144.
CREATE AUTHORIZATION and REPLACE
AUTHORIZATION
Purpose
16
Creates or replaces an authorization object in Teradata Database. The authorization stores credentials for a user account that exists on a remote platform. The credentials need only be valid on the platform specified in the foreign server object; they do not need to be valid on the Teradata Database or on its underlying operating system. When you specify TRUSTED in the CREATE or REPLACE AUTHORIZATION statement, Teradata Database does not validate the credentials.
For Teradata QueryGrid, an authorization object is used by a foreign server object to log into a remote platform using credentials that are valid on the remote platform. When a Teradata user makes a request that uses the foreign server, the foreign server object provides the credentials from the authorization object to the target platform for authentication. This allows any part of the request that runs on the remote platform to use the context, privileges, and access control granted to the remote platform user account.
For example, if the foreign server connects to another Teradata Database that authenticates users using the OS platform, then the associated authorization object must contain credentials for the OS platform user account.
Teradata QueryGrid: Teradata Database-to-Teradata Database
Syntax
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE AUTHORIZATION and REPLACE AUTHORIZATION
The syntax table describes only the portions of the CREATE AUTHORIZATION and
REPLACE AUTHORIZATION syntax diagram that are specific to Teradata QueryGrid. For information about the other syntax that you can use with CREATE AUTHORIZATION and
REPLACE AUTHORIZATION, see SQL Data Definition Language - Syntax and Examples,
B035-1144.
Syntax Element
We recommend that you create the authorization on TD_SERVER_DB using the TRUSTED
DEFINER type. This methodology makes the authorization available globally and helps to insure that authorizations work correctly.
TRUSTED
A keyword that associates a name with the credentials used to access the foreign server so that so that the credentials are encrypted and stored as database objects.
You must use the TRUSTED security type for Teradata QueryGrid: Teradata Databaseto-Teradata Database authorizations.
• If you specify DEFINER TRUSTED or DEFINER DEFAULT TRUSTED, then
Teradata looks for authorization credentials only in the TD_SERVER_DB database.
You can use this syntax, for example, to set up a centrally located server with credentials that multiple users can access.
• If you specify INVOKER TRUSTED, or if you specify TRUSTED alone, Teradata looks for authorization credentials for the user who invokes the object.
You cannot use TRUSTED authorizations in CREATE or REPLACE UDF or XSP statements.
All existing rules for CREATE AUTHORIZATION and REPLACE AUTHORIZATION apply.
For more information about using CREATE AUTHORIZATION and REPLACE
AUTHORIZATION, see SQL Data Definition Language - Syntax and Examples, B035-1144.
Usage Notes
• A proxy user can be used by one or more trusted authorization objects. To drop the proxy, you need to drop the authorization on the proxy. For example:
DROP FOREIGN SERVER TD_SERVER_DB.remote_system ;
DROP AUTHORIZATION TD_SERVER_DB.remote_proxy ;
Teradata QueryGrid: Teradata Database-to-Teradata Database 17
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE AUTHORIZATION and REPLACE AUTHORIZATION
You do not have to drop the foreign server objects that are used by the proxy, but it is a best practice to do so, because you must have an authorization associated with a foreign server object in order to reference the object. If you drop an authorization but do not drop a foreign server object that uses it, then the next time that you try to reference the foreign server object, you get an error message.
• The proxy users who are configured to use the Teradata-to-Teradata connector are users who are defined on the remote Teradata system. A DBA on the remote Teradata system can drop these individual Teradata users on the remote Teradata system without any constraints.
However, before a DBA on the remote Teradata system drops a remote proxy user, a DBA on the local Teradata system should drop the authorization and foreign server objects as well. If the authorization and foreign server objects on the local Teradata system are not dropped first, users see errors during query execution.
• If the credentials change on the foreign server's target platform, you must remember to replace the credentials in the authorization object. If you fail to update the invalid information, the next time that you try to reference the foreign server object, you get an error message.
• If you drop an authorization object, keep in mind that it may be used by multiple foreign server objects. You should either drop the foreign server objects or alter them so that they specify a valid authorization object. If you fail to update the invalid information, the next time that you try to reference the foreign server object, you get an error message.
Examples of Creating and Replacing the Authorization
If you want to make the authorization available globally, create the authorization on
TD_SERVER_DB using the DEFINER TRUSTED type.
CREATE AUTHORIZATION TD_SERVER_DB.remote_system1
AS DEFINER TRUSTED USER 'proxy_1'
PASSWORD 'Global' ;
If you use DEFINER TRUSTED, as in this example, then the credentials for sales must be created in the TD_SERVER_DB database.
CREATE AUTHORIZATION TD_SERVER_DB.sales AS DEFINER TRUSTED
USER 'johnson'
PASSWORD 'Secret';
The following two examples establish authorization for the user who invokes the object. The credentials are encrypted and stored in the user database as an object.
CREATE AUTHORIZATION sales AS TRUSTED
USER 'johnson'
PASSWORD 'Secret' ;
REPLACE AUTHORIZATION sales AS INVOKER TRUSTED
USER 'williams'
PASSWORD 'topsecret' ;
18 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE FOREIGN SERVER
CREATE FOREIGN SERVER
Purpose
Syntax
CREATE FOREIGN SERVER
Creates a foreign server object and associates table operators with it.
When you create a server object, you can customize it based on its purpose. You can define multiple server objects for the same remote database, each with different characteristics needed by different users.
server_name
A
TD_SERVER_DB.
EXTERNAL SECURITY TRUSTED
authorization_name
A
using option
DO IMPORT WITH
operator option
;
, DO EXPORT WITH
operator option
DO EXPORT WITH
operator option
, DO IMPORT WITH
operator option operator option
table_operator
using option
database_name.
Syntax Elements
server_name
The name given to the foreign server object. Foreign server objects are stored in the
TD_SERVER_DB database.
EXTERNAL SECURITY TRUSTED
Associates an authorization object with the foreign server. The authorization stores the encrypted credentials for a user as a database object. The QueryGrid connector passes the credentials in the authorization to the remote platform identified by the foreign server when the foreign server is accessed.
You must use the TRUSTED security type for Teradata QueryGrid: Teradata Database-to-
Teradata Database.
authorization_name
Specifies the name of the authorization object to be used when the foreign server is accessed.
Teradata QueryGrid: Teradata Database-to-Teradata Database 19
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE FOREIGN SERVER
USING Option
USING introduces the global name value pairs that provide the server definition information. USING must be followed by at least one name value pair.
Note: With the exception of the port NVP, do not use surrounding apostrophes (single quotation marks) for name value pairs that are composed entirely of integers. NVPs that contain only integers are handled differently from those that contain alphabetic strings, alphanumeric strings, or characters and integers, such as an IP address. If you delimit an integer value with apostrophes, then the value is silently ignored and the default value is used instead.
Required Name Value Pairs
Attributes that define a server object are called global name value pairs.
hosttype
The type of host to connect to. This value must be
Teradata
.
ip_device local_ips
The DNS name of the local Teradata nodes or the IP addresses of the local Teradata nodes. One or the other is required, but not both. ip_device
supports a common node device name, but the device name found by using ifconfig must be on the same network for all nodes of the system.
port
The local port number to which the remote Teradata Database system can connect. The default is 5000. This port must remain open. If you run any other application on the system that listens on port 5000, then you must specify a different port number in the
CREATE or ALTER FOREIGN SERVER statement.
remotehost
The DNS host name or IP address of the remote Teradata Database system.
Optional Name Value Pairs bytecountreportfreq
The frequency with which progress is updated in Viewpoint. The default is 64K, which corresponds to each block. You can adjust this to a larger value if the update frequency of once per block is too resource-intensive.
Users can override this value at the query level by using a session QUERY_BAND name value pair. For example:
SET QUERY_BAND = 'bytecountreportfreq=256;' FOR SESSION;
concurrentstreams
The parallel efficiency to use. This value determines the number of parallel socket connections that are established between a local Teradata node and a remote Teradata node.
The valid range is 1 to 5. The default value is 1. With a value of 1, a node on the remote system reads the requested data and uses the established socket connection to send the data in 64KB blocks to a node on the local system.
20 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE FOREIGN SERVER
If your network bandwidth setup can support higher values, users may want to override this server value at the query level by using a session QUERY_BAND name value pair.
For example:
SET QUERY_BAND = 'concurrentstreams=2;' FOR SESSION;
dbname
The database to use. You can use the dbname name value pair in the server object to limit access to specific databases. The database name in the server object overrides users' selections.
disable_pushdown
When set to true, disables the pushdown of all query conditions to the remote system.
Valid values are true and false. By default, this NVP is set to false.
Certain system level, session level, and column level query attributes (such as casespecific) can affect character string comparison results. These attributes can cause some queries to return incorrect results due to incorrect row filtering on the remote system.
To avoid incorrect results caused by condition pushdown in situations where the settings on the local system do not match the settings on the remote system, you can disable the pushdown of all conditions to the remote system.
For example, consider the following query and its EXPLAIN: explain SELECT * from UPTT48.table1@MyforeignServer where x2 < '012';
The following EXPLAIN illustrates the processing of the query when disable_pushdown
is set to true
, and therefore no condition pushdown takes place during processing.
Explanation
-----------------------------------------------------------------------
1) First, we do an all-AMPs RETRIEVE step executing table operator
syslib.load_from_td with a condition of ("table1.X2 < '012 '").
< BEGIN EXPLAIN FOR REMOTE QUERY -->
We get external query:'SELECT x1 ,x2 FROM UPTT48.table1 WHERE X2 <
'012 '' for target system:server1.mycompany.com. 1) First, we
lock a distinct UPTT48."pseudo table" for read on a RowHash to
prevent global deadlock for UPTT48.table1. 2) Next, we lock
UPTT48.table1 for read. 3) We do an all-AMPs RETRIEVE step from
UPTT48.table1 by way of an all-rows scan with a condition of
("UPTT48.table1.x2 < '012 '") executing table operator
SYSLIB.load_to_tdRemote with a condition of ("(1=1)") into Spool 2
(used to materialize view, derived table, table function or table
operator d) (all_amps), which is built locally on the AMPs.
The size of Spool 2 is estimated with no confidence to be 3 rows
(64,068 bytes). The estimated time for this step is 0.16 seconds.
4) We do an all-AMPs RETRIEVE step from Spool 2 (Last Use) by way
of an all-rows scan into Spool 3 (group_amps), which is built
locally on the AMPs. The size of Spool 3 is estimated with no
confidence to be 3 rows (64,068 bytes). The estimated time for
this step is 0.16 seconds. 5) Finally, we send out an END
TRANSACTION step to all AMPs involved in processing the request.
-> The contents of Spool 3 are sent back to the user as the result
of statement 1. The total estimated time is 0.32 seconds.
<-- END EXPLAIN FOR REMOTE QUERY >
Teradata QueryGrid: Teradata Database-to-Teradata Database 21
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE FOREIGN SERVER
The size of Spool 1 is estimated with low confidence to be 80,000
rows (2,800,000 bytes). The estimated time for this step is 0.13
seconds.
2) Next, we do an all-AMPs RETRIEVE step from Spool 1 (Last Use) by
way of an all-rows scan with a condition of ("table1.X2 < '012 '")
into Spool 2 (group_amps), which is built locally on the AMPs.
The size of Spool 2 is estimated with no confidence to be 80,000
rows (3,360,000 bytes). The estimated time for this step is 0.54
seconds.
3) Finally, we send out an END TRANSACTION step to all AMPs involved
in processing the request.
-> The contents of Spool 2 are sent back to the user as the result of
statement 1. The total estimated time is 0.67 seconds.
The following EXPLAIN illustrates the processing of the query when disable_pushdown is set to false
, and therefore condition pushdown takes place during processing.
Explanation
-----------------------------------------------------------------------
1) First, we do an all-AMPs RETRIEVE step executing table operator
syslib.load_from_td with a condition of ("table1.X2 < '012 '").
< BEGIN EXPLAIN FOR REMOTE QUERY -->
We get external query:'SELECT x1 ,x2 FROM UPTT48.table1 ' for
target system:server1.mycompany.com. 1) First, we lock a distinct
UPTT48."pseudo table" for read on a RowHash to prevent global
deadlock for UPTT48.table1. 2) Next, we lock UPTT48.table1 for
3) We do an all-AMPs RETRIEVE step from UPTT48.table1 by way of an
read. all-rows scan with no residual conditions executing table
operator SYSLIB.load_to_tdRemote with a condition of ("(1=1)")
into Spool 2 (used to materialize view, derived table, table
function or table operator d) (all_amps), which is built locally
on the AMPs. The size of Spool 2 is estimated with low confidence
to be 8 rows (170,848 bytes). The estimated time for this step
is 0.16 seconds.
4) We do an all-AMPs RETRIEVE step from Spool 2 (Last Use) by way
of an all-rows scan into Spool 3 (group_amps), which is built
locally on the AMPs. The size of Spool 3 is estimated with low
confidence to be 8 rows (170,848 bytes). The estimated time for
this step is 0.16 seconds. 5) Finally, we send out an END
TRANSACTION step to all AMPs involved in processing the request.
-> The contents of Spool 3 are sent back to the user as the result
of statement 1. The total estimated time is 0.32 seconds.
<-- END EXPLAIN FOR REMOTE QUERY >
The size of Spool 1 is estimated with low confidence to be 80,000
rows (2,800,000 bytes). The estimated time for this step is 0.13
seconds.
2) Next, we do an all-AMPs RETRIEVE step from Spool 1 (Last Use) by
way of an all-rows scan with a condition of ("table1.X2 < '012 '")
into Spool 2 (group_amps), which is built locally on the AMPs.
The size of Spool 2 is estimated with no confidence to be 80,000
rows (3,360,000 bytes). The estimated time for this step is 0.54
seconds.
3) Finally, we send out an END TRANSACTION step to all AMPs involved
22 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE FOREIGN SERVER
in processing the request.
-> The contents of Spool 2 are sent back to the user as the result of
statement 1. The total estimated time is 0.67 seconds.
listen_timeout
The number of seconds to wait for one connection while listening. The default is 60 seconds. This value represents the time period in which the query is parsed, runs on the remote system, and returns results to the local system. If you are accessing large tables on the remote system, you may want to increase this value to avoid having queries time out.
Users can override this server value at the query level by using a session QUERY_BAND name value pair. For example:
SET QUERY_BAND = 'listen_timeout=180;' FOR SESSION;
read_timeout
The number of seconds to wait on the socket. The default value is 30.
Users can override this server value at the query level by using a session QUERY_BAND name value pair. For example:
SET QUERY_BAND = 'read_timeout=60;' FOR SESSION;
tablename
The table to use. You can use the tablename name value pair in the server object to limit access to specific tables. The table name in the server object overrides users' selections.
querylogging
The Teradata-to-Teradata connector supports and passes the following server name value pairs to the remote Teradata system:
• listen_timeout
• read_timeout
• concurrentstreams
• bytecountreportfreq
If a user uses SET QUERY_BAND to set any of these values for a session, then the
QUERY_BAND values take precedence over the values that were set when a foreign server object was created or last altered.
When querylogging is set to true by using SET QUERY_BAND on the local system, the connector turns on query logging on the remote system.
Import Operator
DO IMPORT WITH
Associates an IMPORT table operator with a foreign server.
Export Operator
DO EXPORT WITH
Associates an EXPORT table operator with a foreign server.
Teradata QueryGrid: Teradata Database-to-Teradata Database 23
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
CREATE FOREIGN SERVER
Operator Option
database_name.
The name of the database that contains the operator that you want to call. If you use
LOAD_TO_TD or LOAD_FROM_TD, the database_name must be SYSLIB.
table_operator
The name of the table operator to use. These table operators are used to import and export the data between Teradata systems.
Teradata supplies the following table operators for use with the Teradata-to-Teradata connector:
• LOAD_FROM_TD
• LOAD_TO_TD
The LOAD_FROM_TD operator retrieves data from a remote Teradata Database for use in a local Teradata Database, where the data can be placed in tables or joined with existing tables. It produces a spooled table that contains the specified data from the remote system. The query that you use can be part of a larger query and can be joined against other Teradata Database tables and views. The data is imported in parallel from multiple nodes into multiple Teradata Database AMPs.
The LOAD_TO_TD operator exports data from Teradata Database into a remote
Teradata Database, where the data can be placed in tables or joined with existing tables.
Note: The Teradata-to-Teradata connector table operators do not have specific operator options and users cannot call these table operators directly.
Example of Using CREATE FOREIGN SERVER Syntax
This example demonstrates creating a foreign server in Teradata Database. In this instance, the foreign server that you reference is a remote Teradata Database system.
CREATE FOREIGN SERVER remote_system
EXTERNAL SECURITY DEFINER TRUSTED remote_system_proxy
USING
Hosttype('Teradata')
remotehost ('198.51.100.15')
local_ips('192.0.2.24')
port('6001')
read_timeout(200)
listen_timeout(60)
concurrentstreams(1)
DO IMPORT WITH syslib.load_from_td,
DO EXPORT WITH syslib.load_to_td ;
Required Privileges
You must have CREATE SERVER privilege on the TD_SERVER_DB database to define a foreign server object. If you are associating the server with table operators, you must also have EXECUTE FUNCTION and SELECT privileges on the specified table operators.
24 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
DROP FOREIGN SERVER
Usage Notes
• You can create multiple named foreign server objects that reference the same server using the same IP and port numbers.
• Foreign server object names (servers, databases, tables) that are stored in
TD_SERVER_DB must be unique.
• Server options, names, and name value pairs can appear only once in the CREATE
FOREIGN SERVER syntax.
• The order of the DO IMPORT WITH and DO EXPORT WITH clauses in the CREATE
SERVER syntax does not matter.
You cannot use the following names in the name value pairs in CREATE SERVER statements:
• Columns
• hExplain
• IsNested
• If EXTERNAL SECURITY TRUSTED is specified, then you must also avoid the use of
Proxyusername and Proxypass.
• Servermode
DROP FOREIGN SERVER
Purpose
Drops a foreign server object from the TD_SERVER_DB database.
In addition to deleting the server object and its associated information from the dictionary tables, all dependent entries on the associated table operators are deleted.
You must have the DROP SERVER privilege on the TD_SERVER_DB database or on the specified foreign server to DROP the foreign server.
Syntax
DROP FOREIGN SERVER
server_name
TD_SERVER_DB.
;
Syntax Elements
server_name
The name of the foreign server object.
You can also use the following formats for the server name:
• the Unicode Delimited Identifier, such as U&"foreign#005fsv" UESCAPE'#'
• the double-quoted object name, such as "foreign srv1"
TB_SERVER_DB.
The name of the database that stores server objects and their attributes.
Teradata QueryGrid: Teradata Database-to-Teradata Database 25
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
END LOGGING
END LOGGING
Purpose
Ends the auditing of SQL requests that started with a BEGIN LOGGING request.
This topic describes only the portions of the END LOGGING syntax diagram that are specific to Teradata QueryGrid. For information about the other syntax that you can use with
END LOGGING, see SQL Data Definition Language - Syntax and Examples, B035-1144.
Syntax
END LOGGING
A
DENIALS WITH TEXT
FOR CONSTRAINT
constraint_name
ON
BY
ALL
,
operation
GRANT
,
database_name user_name
B
ON
,
20
AUTHORIZATION authorization_name
DATABASE database_name
USER database_name
TABLE
VIEW
MACRO
PROCEDURE
FUNCTION
TYPE
FOREIGN SERVER
database_name.
user_name.
object_name
;
A
B
Syntax Elements
ON operation
Indicates the operation for which log entries should no longer be made.
ON FOREIGN SERVER object_name
Indicates that the operation for which log entries should no longer be made is access to a foreign server.
You must specify an object name, which is the name of the foreign server. You can optionally specify the name of the containing database, which must be
TD_SERVER_DB. You cannot use a user_name with FOREIGN SERVER.
26 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
ExecuteForeignSQL
For information about using END LOGGING, see SQL Data Definition Language - Syntax
and Examples, B035-1144.
ExecuteForeignSQL
Purpose
A stored procedure that provides a simple interface for executing basic SQL queries, such as
CREATE, DROP, DELETE, and GRANT on a foreign server. For example, you can use
ExecuteForeignSQL to create or drop a table in a database on the foreign server.
ExecuteForeignSQL passes all SQL queries through, but it does not return results sets, so if you use it to execute a SELECT or HELP statement, you do not see any results.
Syntax
CALL ExecuteForeignSQL
(
‘query_expression’ , ‘server_name’
)
;
SYSLIB.
Syntax Elements
SYSLIB.
The name of the database where the stored procedure is located.
query_expression
A valid Teradata SQL expression.
The query is passed through unparsed to the foreign server.
server_name
The name of the foreign server.
Usage Notes
ExecuteForeignSQL provides secure execution by using an embedded table operator along with Trusted Sessions to handle logon credential verification.
A DBA can selectively GRANT the privilege to use ExecuteForeignSQL.
To call ExecuteForeignSQL, you must first create a foreign server object that specifies DO
IMPORT WITH SYSLIB.EFSSPOP_TDSQLT.
Note: The name of the efsspop table operator has been changed to efsspop_tdsqlt. If you have defined a foreign server to use the legacy efsspop table operator, then to work with
Release 15.0.1, you need to redefine the foreign server, or use ALTER FOREIGN SERVER to change its import operator to efsspop_tdsqlt.
You must have EXECUTE FUNCTION and SELECT privileges on this operator. You can only associate one import operator at a time with a foreign server, so to run
ExecuteForeignSQL on an existing foreign server that is being used for queries, you can create a separate foreign server object with a different name to use for running
ExecuteForeignSQL.
Teradata QueryGrid: Teradata Database-to-Teradata Database 27
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
GRANT and REVOKE
If you reference a table name, you must prepend it with the database name.
SQL queries that return result sets, such as SELECT or HELP, are executed on the remote system, but the resultant rows are not displayed. The query may continue to use CPU, memory and I/O resources on the remote system.
ExecuteForeignSQL uses a proxyuser, so the execution of commands on behalf of DBC is not supported.
Examples of Using ExecuteForeignSQL
Before you can call ExecuteForeignSQL, you must create the foreign server object and specify
DO IMPORT WITH SYSLIB.EFSSPOP_TDSQLT. For example:
CREATE FOREIGN SERVER TD_SERVER_DB.remote_system
EXTERNAL SECURITY DEFINER TRUSTED remote_system_proxy
USING
hosttype ('Teradata')
remotehost ('198.51.100.15')
port ('6000')
local_ip ('198.51.100.24')
DO IMPORT WITH SYSLIB.EFSSPOP_TDSQLT;
The example that follows deletes a table on the foreign server:
CALL SYSLIB.ExecuteForeignSQL('DELETE STORE.Item_Price
WHERE item_no = 2504;','remote_system');
GRANT and REVOKE
GRANT grants one or more explicit privileges on a database, foreign server, user, proxy logon user, table, hash index, join index, view, stored procedure, User-Defined Function
(UDF), User-Defined Method (UDM), User-Defined Type (UDT), or macro to a role, group of roles, user, or group of users or databases. REVOKE revokes privileges on the same objects.
There are no changes to existing syntax for Teradata QueryGrid, except that CREATE
SERVER and DROP SERVER privileges have been added. These privileges should be granted only to a user, not to a database.
Note: You are not allowed to GRANT CONNECT THROUGH privilege on the DBC user.
For a syntax diagram and description of the syntax elements that you can use in GRANT and
REVOKE, see SQL Data Control Language, B035-1149.
28 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
HELP FOREIGN
HELP FOREIGN
Purpose
Returns the details of the foreign object that you specify.
• A foreign server object name returns the list of databases accessible on the server.
• The name of a database on a foreign server returns the list of tables in the remote database on the server.
• The name of a table in a remote database on a foreign server returns the list of columns in the remote table on the server.
Syntax
db_name.table_name@server_name
Syntax Elements
SERVER server_name
The name of the foreign server. Displays the databases in the foreign server.
DATABASE db_name@server_name
The name of the remote database, qualified with the name of the foreign server. Displays the tables in the database.
TABLE db_name.table_name@server_name
The name of the remote table, qualified with the name of the foreign server. Displays the column names, types, and partitioning.
Required Privileges
To display the output from HELP FOREIGN, on the local server, you must have ANY privilege on the server object. Additional privileges are required to set up on the remote system for the connecting user. For information about the privileges needed to set up the remote system, see the information about the privileges needed on table operators and stored procedures in
Privileges Needed to Use Teradata QueryGrid
.
Teradata QueryGrid: Teradata Database-to-Teradata Database 29
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
HELP FOREIGN
Examples: HELP FOREIGN SERVER
Example: Using HELP FOREIGN SERVER
The following query displays the databases available to the user on the remote system:
HELP FOREIGN SERVER remote_system ;
The query returns the following results:
*** Query completed. 27 rows found. One column returned.
*** Total elapsed time was 4 seconds.
DatabaseName
-----------------------------------------------------------------------
----
All
Crashdumps
DBC dbcmngr
Default
EXTUSER
LockLogShredder proxyuser
PUBLIC
SQLJ
SysAdmin
SYSBAR
SYSJDBC
SYSLIB
SYSSPATIAL
SystemFe
SYSUDTLIB
SYSUIF
Sys_Calendar
TDPUSER
TDQCD
TDStats tdwm
TD_SERVER_DB
TD_SYSFNLIB
TD_SYSXML ut1
Example: Using HELP FOREIGN DATABASE
The following query displays the tables available to the user in the database on the remote system:
HELP FOREIGN DATABASE store@remote_system ;
The query returns the following results:
*** Query completed. 6 rows found. 13 columns returned.
*** Total elapsed time was 1 second.
30 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
SHOW FOREIGN SERVER
Table/View/Macro name Kind Comment
------------------------------ ---- ------------
Customer_Order T ?
Inventory T ?
Item_Price T ?
NewItems T ?
Orders T ?
PriceList T ?
Example: Using HELP FOREIGN TABLE
The following query displays a sample of the columns returned, which are the same as when you run a HELP FOREIGN TABLE on the local system:
HELP FOREIGN TABLE store.Item_Price@remote_system ;
The query returns the following results:
*** Query completed. 2 rows found. 27 columns returned.
*** Total elapsed time was 1 second.
Column Name Type Comment
------------------------------ ---- -----------item_no I ?
item_price D ?
SHOW FOREIGN SERVER
Purpose
Displays the SQL text most recently used to create, drop, or modify the server object.
A SHOW FOREIGN SERVER statement allows you to see a server object definition that contains the name value pairs that the associated table operators use to connect to the foreign server.
Syntax
SHOW FOREIGN SERVER
server_name
IN XML TB_SERVER_DB.
Syntax Elements
IN XML
To return the report in XML format.
The XML schema for the output produced by this option is maintained in: http://schemas.teradata.com/dbobject/DBobject.xsd
Teradata QueryGrid: Teradata Database-to-Teradata Database
;
31
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using EXPLAINs With Remote Queries
server_name
The name of the foreign server object.
For the full syntax diagram and information about the other objects that can be used with
SHOW, see SQL Data Definition Language - Syntax and Examples, B035-1144.
Required Privileges
SHOW FOREIGN SERVER requires SHOW privilege or ANY privilege on the server object to display the output.
Example of Using SHOW FOREIGN SERVER Syntax
SHOW FOREIGN SERVER remote_system ;
This query generates the following output:
*** Text of DDL statement returned.
*** Total elapsed time was 1 second.
-----------------------------------------------------------------------
CREATE FOREIGN SERVER TD_SERVER_DB.remote_system
EXTERNAL SECURITY DEFINER TRUSTED remote_system_proxy USING concurrentstreams (2 )
Hosttype ('Teradata') remotehost ('198.51.100.15') local_ips ('192.0.2.24') port ('6001') read_timeout (200 ) listen_timeout (60 )
DO IMPORT WITH SYSLIB.LOAD_FROM_TD ,
DO EXPORT WITH SYSLIB.LOAD_TO_TD ;
Using EXPLAINs With Remote Queries
When you use the Teradata-to-Teradata connector to query a remote system, the EXPLAINs show the explain plan for the remote query as part of the local query. The row statistics that are generated for the remote query are not retrieved and are not integrated into the local plan. In release 15.0, the local plan by default assumes that the remote spool size is 10K rows per AMP.
32 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector with SELECT Statements
Using the Teradata-to-Teradata Connector with
SELECT Statements
You can use the foreign server grammar in the form of
database_name.table_name@server_name in SELECT statements. If you do not specify a database, it defaults to the current database.
You can use this foreign server grammar in joins and any other place that you reference a normal table, including views, macros, and stored procedures.
Logical expressions such as AND, OR, NOT, >, <, and so on, are supported.
The standard Teradata limits, such as returning up to 2048 columns, apply. Row size must be less than 64K.
For a list of the supported data types, see Introduction to Teradata QueryGrid: Teradata
Database-to-Teradata Database Syntax
.
Example: Using SELECT
This query illustrates the use of SELECT to import data. The query pushes the WHERE clause down to the remote database when the column is compared against a constant expression. Expressions that include columns from a local Teradata Database table are evaluated locally during the AMP qualification of the row as it is placed in spool.
SELECT item_no, item_price
FROM STORE.Item_Price@remote_system
WHERE item_price<20.00;
It results in the following output:
*** Query completed. 2 rows found. 2 columns returned.
*** Total elapsed time was 5 seconds.
item_no item_price
----------- ------------
2503 7.50
2504 8.75
Example: Using SELECT with a View
You can also create views using the foreign server grammar. In this query, a WHERE clause external to the view is pushed down to the remote system. The Item_Inv_Price_vw view sets up a remote query joined with a local table. The WHERE clause in the SELECT appears in the EXPLAIN for the remote system.
CREATE VIEW Item_Inv_Price_vw AS (
SELECT p.item_no, m.item_desc, SUM(i.item_qty * p.item_price)
AS inventory_value
FROM STORE.Item_Price@remote_system p,
STORE.Item_Inventory i,
STORE.Item_Master m
Teradata QueryGrid: Teradata Database-to-Teradata Database 33
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector with SELECT Statements
GROUP BY p.item_no, m.item_desc
WHERE p.item_no=i.item_no
AND p.item_no=m.item_no );
SELECT * FROM Item_Inv_Price_vw;
*** Query completed. 4 rows found. 3 columns returned.
*** Total elapsed time was 6 seconds.
item_no item_desc inventory_value
----------- -------------------- -----------------
2503 Oil Filter, M52 120.00
2501 Air Cleaner, E46 139.95
2504 Oil Filter, M60 17.50
2502 Air Cleaner, E60 419.88
You can use EXPLAIN to see how Teradata Database handles a query. For example:
EXPLAIN SELECT inventory_value FROM Item_Inv_Price_vw WHERE item_no <>
0;
The EXPLAIN for this query is as follows:
Explanation
----------------------------------------------------------------------
This request is eligible for incremental planning and execution (IPE).
The following is the static plan for the request.
1) First, we lock STORE.m in view TDUSER.Item_Inv_Price_vw for read
on a reserved RowHash to prevent global deadlock.
2) Next, we lock STORE.i in view TDUSER.Item_Inv_Price_vw for read on
a reserved RowHash to prevent global deadlock.
3) We lock STORE.m in view TDUSER.Item_Inv_Price_vw for read, and we
lock STORE.i in view TDUSER.Item_Inv_Price_vw for read.
4) We do an all-AMPs RETRIEVE step executing table operator
syslib.load_from_td with a condition of ("p.ITEM_NO NOT IN (0)").
< BEGIN EXPLAIN FOR REMOTE QUERY -->
We get external query:'SELECT ITEM_NO ,ITEM_PRICE FROM
STORE.Item_Price ' for target system:198.51.100.15.
1) First, we lock STORE.Item_Price for read on a reserved RowHash
to prevent global deadlock. 2) Next, we lock STORE.Item_Price for
read. 3) We do an all-AMPs RETRIEVE step from STORE.Item_Price by
way of an all-rows scan with no residual conditions executing
table operator SYSLIB.load_to_tdRemote with a condition of
("(1=1)") into Spool 2 (used to materialize view, derived table,
table function or table operator d) (all_amps), which is built
locally on the AMPs. The size of Spool 2 is estimated with low
confidence to be 4 rows (42,756 bytes). The estimated time for
this step is 0.08 seconds. 4) We do an all-AMPs RETRIEVE step from
Spool 2 (Last Use) by way of an all-rows scan into Spool 3
(group_amps), which is built locally on the AMPs. The size of
Spool 3 is estimated with low confidence to be 4 rows (42,756
bytes). The estimated time for this step is 0.08 seconds.
5) Finally, we send out an END TRANSACTION step to all AMPs
involved in processing the request. -> The contents of Spool 3 are
34 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector with SELECT Statements
sent back to the user as the result of statement 1. The total
estimated time is 0.16 seconds.
<-- END EXPLAIN FOR REMOTE QUERY >
The size of Spool 1 is estimated with low confidence to be 4 rows
(116 bytes). The estimated time for this step is 0.06 seconds.
5) We execute the following steps in parallel.
1) We do an all-AMPs RETRIEVE step from Spool 1 (Last Use) by
way of an all-rows scan with a condition of ("p.ITEM_NO NOT
IN (0)") into Spool 5 (all_amps), which is redistributed by
hash code to all AMPs to all AMPs. Then we do a SORT to
order Spool 5 by row hash. The size of Spool 5 is estimated
with low confidence to be 4 rows (88 bytes). The estimated
time for this step is 0.03 seconds.
2) We do an all-AMPs JOIN step from STORE.m in view
TDUSER.Item_Inv_Price_vw by way of a RowHash match scan with
a condition of ("STORE.m in view
TDUSER.Item_Inv_Price_vw.ITEM_NO <> 0"), which is joined to
STORE.i in view TDUSER.Item_Inv_Price_vw by way of a RowHash
match scan with a condition of ("STORE.i in view
TDUSER.Item_Inv_Price_vw.ITEM_NO <> 0"). STORE.m and STORE.i
are joined using a merge join, with a join condition of (
"STORE.i.ITEM_NO = STORE.m.ITEM_NO"). The result goes into
Spool 6 (all_amps), which is redistributed by hash code to
all AMPs to all AMPs. Then we do a SORT to order Spool 6 by
row hash. The size of Spool 6 is estimated with low
confidence to be 5 rows (145 bytes). The estimated time for
this step is 0.05 seconds.
6) We do an all-AMPs JOIN step from Spool 5 (Last Use) by way of a
RowHash match scan, which is joined to Spool 6 (Last Use) by way
of a RowHash match scan. Spool 5 and Spool 6 are joined using a
merge join, with a join condition of ("(ITEM_NO = ITEM_NO) AND
(ITEM_NO = ITEM_NO)"). The result goes into Spool 4 (all_amps),
which is built locally on the AMPs. The size of Spool 4 is
estimated with index join confidence to be 10 rows (310 bytes).
The estimated time for this step is 0.11 seconds.
7) We do an all-AMPs SUM step to aggregate from Spool 4 (Last Use) by
way of an all-rows scan, and the grouping identifier in field 1.
Aggregate Intermediate Results are computed globally, then placed
in Spool 7. The size of Spool 7 is estimated with no confidence
to be 6 rows (198 bytes). The estimated time for this step is
0.11 seconds.
8) We do an all-AMPs RETRIEVE step from Spool 7 (Last Use) by way of
an all-rows scan into Spool 2 (group_amps), which is built locally
on the AMPs. The size of Spool 2 is estimated with no confidence
to be 6 rows (192 bytes). The estimated time for this step is
0.08 seconds.
9) Finally, we send out an END TRANSACTION step to all AMPs involved
in processing the request.
-> The contents of Spool 2 are sent back to the user as the result of
statement 1. The total estimated time is 0.42 seconds.
Teradata QueryGrid: Teradata Database-to-Teradata Database 35
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector with SELECT Statements
Example: Using SELECT with FOREIGN TABLE Syntax
The FOREIGN TABLE SELECT grammar provides a pass through mechanism that pushes a sub-query down to be executed on the remote database. You can use this mechanism to have the remote system qualify the data before you import it into a local database.
The following query demonstrates the pass through query in the parentheses of the
FOREIGN TABLE clause. You can use a WHERE clause or GROUP BY clause, but you cannot use an ORDER BY clause.
SELECT * FROM FOREIGN TABLE(
SELECT o.order_no, p.item_no, SUM(o.item_qty * p.item_price)
AS item_value
FROM STORE.Item_Price p, STORE.Customer_Order o
GROUP BY o.order_no, p.item_no
WHERE p.item_no=o.item_no
)@remote_system as dt;
This query produces the following output:
*** Query completed. 4 rows found. 3 columns returned.
*** Total elapsed time was 5 seconds.
order_no item_no item_value
----------- ----------- -----------------
10002 2501 139.95
10001 2502 174.95
10001 2501 279.90
10003 2501 559.80
The FOREIGN TABLE SELECT statement is used as a sub-query in the ON clause of the
LOAD_TO_TD remote export table operator. The data is then imported into Teradata’s spool. You should use this type of statement if you want to join multiple tables on the remote system, use GROUP BY aggregations, or reduce the data before you import it.
Example: Using SELECT to Import Data
You can import data into a permanent or temporary Teradata Database table. If you need to run multiple queries against the data in a session, saving the rows into another table speeds up subsequent queries. You can use a CREATE TABLE AS statement to create the table, as in the following query:
CREATE TABLE Item_Price_copy AS (SELECT *
FROM STORE.Item_Price@remote_system)
WITH DATA PRIMARY INDEX (item_no);
SELECT * FROM Item_Price_Copy;
This query produces the following output:
*** Query completed. 4 rows found. 2 columns returned.
*** Total elapsed time was 1 second.
item_no item_price
----------- ------------
2502 34.99
36 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector with SELECT Statements
2504 8.75
2501 27.99
2503 7.50
Example: Joining a Remote Table with a Local Teradata Database Table
You can join one or more remote tables in a query with a local Teradata Database table. In this example, the remote data from store.pricelist is imported to the Teradata spool and redistributed before it is joined with the inventory table.
SELECT p.item_no, SUM(i.item_qty * item_price)
AS item_value
FROM STORE.Item_Price@remote_system p, Item_Inventory i
GROUP BY p.item_no
WHERE p.item_no=i.item_no;
The output from this query looks as follows:
*** Query completed. 4 rows found. 2 columns returned.
*** Total elapsed time was 6 seconds.
item_no item_value
----------- -----------------
2502 419.88
2504 17.50
2501 139.95
2503 120.00
Using EXPLAIN to Understand SELECT Queries
You can use an EXPLAIN to describe how remote queries will be handled. For example, consider the following query:
EXPLAIN SELECT * from STORE.Item_Price@remote_system where b = 1000;
This query returns the following output:
Explanation
---------------------------------------------------------------------------
1) First, we do an all-AMPs RETRIEVE step executing table operator
syslib.load_from_td with a condition of ("Item_Price.B = 1000").
< BEGIN EXPLAIN FOR REMOTE QUERY -->
We get external query:'SELECT a ,b ,c FROM STORE.Item_Price WHERE
B = 1000' for target system:remote_system.mycompany.com. 1) First,
we lock STORE.Item_Price for read on a reserved RowHash to prevent
global deadlock. 2) Next, we lock STORE.Item_Price for read. 3) We do
an all-AMPs RETRIEVE step from STORE.Item_Price by way of an all-rows
scan with a condition of ("STORE.Item_Price.b = 1000") into Spool 1
(used to materialize view, derived table, table function or table
operator TblOpInputSpool) (all_amps), which is built locally on the
AMPs. The size of Spool 1 is estimated with no confidence to be 1 row
(229 bytes). The estimated time for this step is 0.15 seconds.
4) We do an all-AMPs RETRIEVE step from Spool 1 (Last Use) by way
of an all-rows scan executing table operator SYSLIB.load_to_tdRemote
Teradata QueryGrid: Teradata Database-to-Teradata Database 37
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector in INSERT Statements to Export Data
with a condition of ("(1=1)") into Spool 2 (used to materialize view,
derived table, table function or table operator d) (all_amps), which
is built locally on the AMPs. The size of Spool 2 is estimated with
no confidence to be 1 row (21,356 bytes). The estimated time for this
step is 0.16 seconds. 5) We do an all-AMPs RETRIEVE step from Spool 2
(Last Use) by way of an all-rows scan into Spool 3 (group_amps), which
is built locally on the AMPs. The size of Spool 3 is estimated with no
confidence to be 1 row (21,356 bytes). The estimated time for this
step is 0.16 seconds. 6) Finally, we send out an END TRANSACTION
step to all AMPs involved in processing the request. -> The
contents of Spool 3 are sent back to the user as the result of
statement 1. The total estimated time is 0.47 seconds.
<-- END EXPLAIN FOR REMOTE QUERY >
The size of Spool 1 is estimated with low confidence to be 8 rows
(1,832 bytes). The estimated time for this step is 0.13 seconds.
2) Next, we do an all-AMPs RETRIEVE step from Spool 1 (Last Use) by
way of an all-rows scan with a condition of ("Item_Price.B = 1000")
into Spool 2 (group_amps), which is built locally on the AMPs. The
size of Spool 2 is estimated with low confidence to be 8 rows (
1,944 bytes). The estimated time for this step is 0.16 seconds.
3) Finally, we send out an END TRANSACTION step to all AMPs involved
in processing the request.
-> The contents of Spool 2 are sent back to the user as the result of
statement 1. The total estimated time is 0.29 seconds.
The EXPLAIN text shows the execution of the LOAD_FROM_TD table operator on the local system, and also includes the EXPLAIN for the remote query, which is located between the
BEGIN EXPLAIN FOR REMOTE QUERY and END EXPLAIN FOR REMOTE QUERY text.
The remote query portion shows the execution of the remote table operator,
LOAD_TO_TDREMOTE, on the remote system, as well as the push down of the WHERE condition.
Note: If you have queries where you could obtain incorrect results because the settings on the local system do not match the settings on the remote system, you can disable the push down of all conditions. For more information, see the disable_pushdown name value pair in
.
Using the Teradata-to-Teradata Connector in
INSERT Statements to Export Data
Example: Exporting Data
You can export data to the remote system by using an INSERT statement to place data into an existing table. The table can be empty or it can contain data. If the table already contains data, the exported data is appended to the existing table’s data.
INSERT INTO STORE.Item_Price@remote_system
SELECT m.item_no, 0.00
FROM STORE.Item_Master m
38 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector in INSERT Statements to Export Data
WHERE m.item_no NOT IN (SELECT item_no FROM
STORE.Item_Price@remote_system) ;
You can insert specific named columns into a remote table as well as constant data, as demonstrated in the following query:
INSERT INTO STORE.Item_Price@remote_system VALUES(2501,27.99) ;
Using EXPLAIN to Understand INSERT Queries
You can use an EXPLAIN to describe how remote queries are handled. For example, consider the following query:
EXPLAIN INSERT INTO STORE.Item_Price@remote_system
SELECT m.item_no, 0.00
FROM STORE.Item_Master m
WHERE m.item_no NOT IN (SELECT item_no FROM
STORE.Item_Price@remote_system ) ;
This query returns the following output:
*** Help information returned. 105 rows.
*** Total elapsed time was 1 second.
Explanation
--------------------------------------------------------------------------------
1) First, we lock STORE.m for read on a reserved rowHash to prevent
global deadlock.
2) Next, we lock STORE.m for read.
3) We do an all-AMPs RETRIEVE step executing table operator
syslib.load_from_td with a condition of ("(1=1)").
< BEGIN EXPLAIN FOR REMOTE QUERY -->
We get external query:'SELECT item_no FROM STORE.Item_Price ' for
target system:198.51.100.15. 1) First, we lock a distinct
STORE."pseudo table" for read on a RowHash to prevent global
deadlock for STORE.Item_Price. 2) Next, we lock STORE.Item_Price
for read. 3) We do an all-AMPs RETRIEVE step from STORE.Item_Price
by way of an all-rows scan with no residual conditions into Spool
1 (group_amps), which is built locally on the AMPs. The size of
Spool 1 is estimated withlow confidence to be 4 rows (100 bytes).
The estimated time for this step is 0.07 seconds. -> The contents
of Spool 1 are flushed to disk and sent back to the user as the
result of statement 1. The total estimated time is 0.07 seconds.
<-- END EXPLAIN FOR REMOTE QUERY >
The size of Spool 1 is estimated with low confidence to be 4 rows
(100 bytes). The estimated time for this step is 0.06 seconds.
4) We execute the following steps in parallel.
1) We do an all-AMPs RETRIEVE step from Spool 1 (Last Use) by
way of an all-rows scan into Spool 4 (all_amps), which is
redistributed by hash code to all AMPs to all AMPs. Then we
do a SORT to order Spool 4 by row hash and the sort key in
spool field1 eliminating duplicate rows. The size of Spool 4
is estimated with no confidence to be 3 rows (63 bytes). The
estimated time for this step is 0.08 seconds.
Teradata QueryGrid: Teradata Database-to-Teradata Database 39
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector in INSERT Statements to Export Data
2) We do an all-AMPs SUM step to aggregate from STORE.m by way
of an all-rows scan with no residual conditions. Aggregate
Intermediate Results are computed globally, then placed in
Spool 7.
5) We do an all-AMPs SUM step to aggregate from Spool 4 by way of an
all-rows scan. Aggregate Intermediate Results are computed
globally, then placed in Spool 9.
6) We execute the following steps in parallel.
1) We do an all-AMPs RETRIEVE step from Spool 9 (Last Use) by
way of an all-rows scan into Spool 5 (all_amps), which is
duplicated on all AMPs.
2) We do an all-AMPs RETRIEVE step from Spool 7 (Last Use) by
way of an all-rows scan into Spool 6 (all_amps), which is
duplicated on all AMPs.
7) We do an all-AMPs JOIN step from STORE.m by way of an all-rows
scan with no residual conditions, which is joined to Spool 4 by
way of an all-rows scan. STORE.m and Spool 4 are joined using an
exclusion product join, with a join condition of (
"STORE.m.item_no = ITEM_NO"), and null value information in Spool
6 and Spool 5. Skip this join step if null exists. The result
goes into Spool 2 (used to materialize view, derived table, table
function or table operator TblOpInputSpool) (all_amps), which is
built locally on the AMPs. The size of Spool 2 is estimated with
no confidence to be 4 rows (76 bytes). The estimated time for
this step is 0.16 seconds.
8) We do an all-AMPs RETRIEVE step from Spool 4 (Last Use) by way of
an all-rows scan into Spool 11 (all_amps), which is built locally
on the AMPs. Then we do a SORT to order Spool 11 by row hash, and
null value information in Spool 6 and Spool 5. Skip this retrieve
step if there is no null. The size of Spool 11 is estimated with
no confidence to be 3 rows (51 bytes). The estimated time for
this step is 0.03 seconds.
9) We do an all-AMPs JOIN step from STORE.m by way of an all-rows
scan with no residual conditions, which is joined to Spool 11
(Last Use) by way of an all-rows scan. STORE.m and Spool 11 are
joined using an exclusion merge join, with a join condition of (
"STORE.m.item_no = ITEM_NO"), and null value information in Spool
6 (Last Use) and Spool 5 (Last Use). Skip this join step if there
is no null. The result goes into Spool 2 (used to materialize
view, derived table, table function or table operator
TblOpInputSpool) (all_amps), which is built locally on the AMPs.
The size of Spool 2 is estimated with no confidence to be 4 rows (
76 bytes). The estimated time for this step is 0.16 seconds.
10) We do an all-AMPs RETRIEVE step from Spool 2 (Last Use) by way of
an all-rows scan executing table operator syslib.load_to_td with a
condition of ("(1=1)") into Spool 3 (used to materialize view,
derived table, table function or table operator Item_Price)
(all_amps), which is built locally on the AMPs.
< BEGIN EXPLAIN FOR REMOTE QUERY -->
1) First, we lock a distinct STORE."pseudo table" for write on a
RowHash to prevent global deadlock for STORE.Item_Price.
2) Next, we lock STORE.Item_Price for write. 3) We do an all-AMPs
RETRIEVE step executing table operator SYSLIB.load_from_tdRemote
40 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector in INSERT Statements to Export Data
with a condition of ("(1=1)"). The size of Spool 1 is estimated
with low confidence to be 4 rows (132 bytes). The estimated time
for this step is 0.06 seconds. 4) We do an all-AMPs RETRIEVE step
from Spool 1 (Last Use) by way of an all-rows scan into Spool 2
(all_amps), which is redistributed by hash code to all AMPs.
Then we do a SORT to order Spool 2 by row hash. The size of Spool
2 is estimated with low confidence to be 4 rows (100 bytes).
The estimated time for this step is 0.03 seconds. 5) We do an
all-AMPs MERGE into STORE.Item_Price from Spool 2 (Last Use).
The size is estimated with low confidence to be 4 rows.
The estimated time for this step is 1 second. -> No rows are
returned to the user as the result of statement 1. The total
estimated time is 1.10 seconds.
<-- END EXPLAIN FOR REMOTE QUERY >
The size of Spool 3 is estimated with no confidence to be 4 rows (
156 bytes). The estimated time for this step is 0.08 seconds.
11) We do an all-AMPs RETRIEVE step from Spool 3 (Last Use) by way of
an all-rows scan into Spool 12 (Last Use), which is built locally
on the AMPs. The size of Spool 12 (Last Use) is estimated with no
confidence to be 4 rows (284 bytes). The estimated time for this
step is 0.08 seconds.
12) Finally, we send out an END TRANSACTION step to all AMPs involved
in processing the request.
-> No rows are returned to the user as the result of statement 1.
Using an INSERT to Import Data From an ARRAY Type Column
When you use an ARRAY data type with the foreign server grammar in Teradata Database release 15.0, the ARRAY data type is transformed into a VARCHAR type on the remote system and retains that type on the local system. This mechanism makes it possible to import remote ARRAY data and insert it into a local ARRAY type column. To access the data in the SELECT list, it first must be cast to an ARRAY type on the local system. Both systems must have the same definitions set up for the ARRAY type.
Note: You must move an entire array column; the moving of individual array elements is not supported.
For example:
INSERT INTO array_test SELECT * FROM ut1.array_test@remote_system ;
Teradata QueryGrid: Teradata Database-to-Teradata Database 41
Chapter 2 Syntax for Teradata QueryGrid: Teradata Database-to-Teradata Database
Using the Teradata-to-Teradata Connector in INSERT Statements to Export Data
42 Teradata QueryGrid: Teradata Database-to-Teradata Database
CHAPTER 3
System and Security Configuration for Teradata
QueryGrid: Teradata Database-to-Teradata
Database
Privileges Needed to Use Teradata QueryGrid
To import and export data between Teradata and remote hosts, you need to create foreign server objects and manage their access rights.
CREATE SERVER and DROP SERVER are object-level privileges that restrict who can use
CREATE FOREIGN SERVER and DROP FOREIGN SERVER. You must have CREATE
AUTHORIZATION and DROP AUTHORIZATION privileges if you need to work with the authorization objects that are referenced by foreign server objects.
Action
Create a foreign server object.
Drop a foreign server object.
Modify a foreign server object.
Create or replace an authorization object.
Privileges that you must have
• CREATE SERVER privilege on TD_SERVER_DB.
• EXECUTE FUNCTION and SELECT privilege on the table operators or on the SYSLIB database.
DROP SERVER privilege on TD_SERVER_DB or on the server object.
• DROP SERVER privilege on TD_SERVER_DB or on the server object.
• If you add or delete any table operators when you modify the server object, you also need EXECUTE
FUNCTION and SELECT privilege on the table operators or on the SYSLIB database.
Required only if using authorization objects with foreign server objects.
• CREATE AUTHORIZATION privilege to use the
CREATE/REPLACE AUTHORIZATION statement.
• DROP AUTHORIZATION privilege is granted automatically to the creator of the authorization.
Privileges Granted Implicitly to Foreign Server Creators
Foreign server creators are implicitly granted the following privileges on the foreign server object when they create the object:
• SHOW privilege on the foreign server with the WITH GRANT OPTION.
Teradata QueryGrid: Teradata Database-to-Teradata Database 43
Chapter 3 System and Security Configuration for Teradata QueryGrid: Teradata Database-to-Teradata Database
Privileges Needed to Use Teradata QueryGrid
• DROP SERVER privilege with the WITH GRANT OPTION.
• SELECT privilege with the WITH GRANT OPTION.
• If the creators specify the EXPORT option at creation, INSERT privilege WITH GRANT
OPTION.
Privileges Needed on the Table Operators and Stored Procedure
The creator of a foreign server object on the local system must grant EXECUTE FUNCTION and SELECT privileges on LOAD_FROM_TD and LOAD_TO_TD to each user who is going to use that foreign server object on the local system.
The DBA on the remote system must do the following:
• Grant EXECUTE FUNCTION and SELECT privileges on load_from_tdremote and load_to_tdremote to the proxy user.
• If you have users that are enabled via the CONNECT THROUGH privilege, then you must either grant EXECUTE FUNCTION and SELECT privileges on load_from_tdremote and load_to_tdremote to each of them, or grant EXECUTE
FUNCTION on load_from_tdremote and load_to_tdremote to public.
For information about using GRANT CONNECT THROUGH, see SQL Data Control
Language, B035-1149.
You should only grant EXECUTE and SELECT privileges on SYSLIB.EFSSPOP_TDSQLT
locally to the administrators (or users) with privileges to create foreign server objects. You should only grant the EXECUTE PROCEDURE privilege on ExecuteForeignSQL to the administrators (or users) who need to use ExecuteForeignSQL.
Privileges Usage Notes
• You can specify the CREATE SERVER privilege only on the database TD_SERVER_DB.
• Only SELECT, INSERT, and SHOW privileges are allowed on foreign server objects. You must grant SELECT, INSERT, and SHOW privileges on foreign server objects to users who need to query foreign server objects.
• The creator of a foreign server object automatically receives DROP SERVER, SELECT, and SHOW privileges WITH GRANT OPTION on the foreign server object.
• The creator of a foreign server object automatically receives INSERT privilege WITH
GRANT OPTION on the foreign server object if an EXPORT operator is associated with the foreign server object.
• When you GRANT ALL privileges on the TD_SERVER_DB database, CREATE SERVER and DROP SERVER privileges are included in the privileges granted.
GRANT ALL ON and REVOKE ALL ON a foreign server object have different meanings, depending on the table operators that are associated with the specified foreign server:
• Granting or revoking the ALL privilege also grants or revokes SHOW, DROP, and
SELECT privilege on a foreign server.
• The ALL privilege on the TD_SERVER_DB database includes the INSERT privilege for foreign servers that reference export operators.
You are not allowed to GRANT the CONNECT THROUGH privilege to the DBC user.
For information about the syntax of GRANT (SQL Form) and REVOKE (SQL Form), see
SQL Data Control Language, B035-1149.
44 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 3 System and Security Configuration for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata Configuration
Teradata Configuration
Teradata System Configuration
To use the Teradata-to-Teradata connector, you need to configure the two systems as follows:
• Install the Teradata-to-Teradata connector on both Teradata systems.
• Configure and authorize a proxy user on the remote system.
Note: When you create a trusted user, the spool space used on the remote system belongs to the proxy user. You should be sure to configure enough spool space for the proxy user to accommodate the number of users that you expect to log on through the proxy.
• Optionally, configure any JVMOptions that you want to use.
Teradata System Security
The Teradata JDBC driver in the Teradata-to-Teradata connector uses encrypted logons, meaning that the logon password is encrypted in transit over the network to the Teradata
Database.
The listen port is protected by use of a unique security key that is generated for each query by the local contract and passed as a USING clause to the remote system. The remote system uses this key as part of its connection information to protect against unauthorized attempts to listen on the listening port.
One method to control system security is to limit CREATE FOREIGN SERVER privileges to the DBA. The DBA can then grant SELECT and INSERT privileges for the foreign server object to users to access the remote database. The user's SQL statement runs as the user name of the session and that user name is used for security in the remote database. You can maintain system security if you use one-to-one mapping for users on both systems.
Note that if you grant a user access to TD_SERVER_DB, the database that stores server objects, you have also granted that user the ability to create server objects.
Teradata System Security Configuration
To use the Teradata-to-Teradata connector, you need to configure the security of the two systems as follows:
• Configure a proxy user on the remote system that local users can use to log on to the remote Teradata system.
Optionally, you can configure a proxy user on both Teradata systems so that either can act as the remote location for users on the other system.
• Grant the local users the privileges that they need when they log on to the remote system through the proxy user.
• Create trusted authorization for the proxy user.
• Create the foreign server object on the local system.
Optionally, you can create a foreign server object on each Teradata system so that either server can act as the remote system for the users on the other system.
For information about creating a foreign server, see
.
• Optionally, to further enhance the security of the Teradata systems, you can configure the
-XX:IpRange JVMOption on the primary node of the remote system. If you do not set
Teradata QueryGrid: Teradata Database-to-Teradata Database 45
Chapter 3 System and Security Configuration for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata Configuration this JVMOption, then data transfer can occur between any remote system and the local system, provided that the other requirements needed for Teradata-to-Teradata have been met.
Creating a Proxy User and Granting Privileges
You must be a database administrator to create a proxy user on the remote system so that local users can log on to the remote Teradata system. You configure a permanent proxy user to represent the rights of a local user on the remote system. Typically, you configure a proxy user to have no space or permissions except for acting as proxy.
You can optionally configure a proxy user on both systems, so that either can act as the remote data location for users on the other system.
You must then grant to each of the local users the privileges that they need when they log on to the remote system through the proxy user.
For additional information about creating a user, see SQL Data
Definition Language - Syntax
and Examples, B035-1144.
1
Type the following statement to create the proxy user:
CREATE USER proxyuser AS PERM = 0 PASSWORD = mypassword ;
2
Type the following statement to grant the proxy user the privileges needed to log onto the remote system:
GRANT CONNECT THROUGH proxyuser TO PERMANENT username WITHOUT ROLE ;
Creating an Authorization Object for the Server
You need to create an authorization object for the server.
This object stores the proxy credentials for the remote logon and is typically defined as a single global value. To make it global for all users who are granted INSERT or SELECT privileges on the server object, you should create the object in the TD_SERVER_DB database and use the DEFINER attribute when you create it.
For additional information about creating authorization objects, see Security Administration,
B035-1100.
1
For example, you could type the following SQL:
CREATE AUTHORIZATION td_server_db.server_name_proxy AS DEFINER
TRUSTED USER 'proxyuser' PASSWORD 'myproxy_pswrd';
The proxy is then authorized and stored in the TD_SERVER_DB database.
Configuring JVMOptions to Maintain Security
The –XX:IpRange JVM option can be set only on the remote system. The remote system uses the IPRange JVM option to validate the IP addresses that are sent from the local system. If the IP addresses that are sent from the local system are not included in the range that was set in the IPRange JVM option, then the system returns a security violation error. This behavior applies to both SELECT and INSERT operations that originate from the local system.
46 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 3 System and Security Configuration for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata Configuration
If you do not set the -XX:IpRange JVMOption, then data transfer can take place between any remote system and the local system, provided that the other requirements needed for
Teradata-to-Teradata have been met.
You can use a single IP address, or you can provide range of IP addresses in the following formats.
1.[0-56].3.4
1.2.[20-25].4
69.[2-69].5.[8-63]
You can use the asterisk (*) wildcard character to represent all of the addresses in a specific octet.
1.*.20.30
192.168.*.*
You can provide a list of IP ranges separated by commas.
192.0.2.24,1.[0-56].3.*,192.[168-169].*.*,1.2.[20-25].4,153.*.20.30
To set the appropriate IP address restrictions, you can perform the following steps:
1
On the primary node of the Teradata system, create a text file that contains the appropriate IP addresses. List all options in a single line, delimited with a space. For example:
2
JVMOptions: -XX:IpRange=192.0.2.24
Name the file itjvmopt.txt and put it in the following location:
/etc/opt/teradata/tdconfig/jvmconfig/
Run the following command:
3
cufconfig –f /etc/opt/teradata/tdconfig/jvmconfig/jvmopt.txt
Then, run the following command to make sure that the JVMOptions property appears on the bottom of the output and that its value has been updated with the values specified in your itjvmopt.txt file: cufconfig -o
The bottom of the output should look similar to this:
USRLibraryPath: /usr/tdbms/lib
JVMOptions: -XX:IpRange=192.0.2.24
4
Restart the database so that the new JVM options take effect.
Teradata QueryGrid: Teradata Database-to-Teradata Database 47
Chapter 3 System and Security Configuration for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata Configuration
48 Teradata QueryGrid: Teradata Database-to-Teradata Database
CHAPTER 4
Administration of Teradata QueryGrid: Teradata
Database-to-Teradata Database
Archive and Restore
Database DBC.TD_SERVER_DB stores all the database objects created using the QueryGrid connector. Note the following about archiving or restoring this database:
• Archive and restore TD_SERVER_DB as a user database. It is not archived and restored as part of DBC.
• You can archive and restore the entire database or individual objects in the database.
• Teradata archives the associated rows from DBC.ServerInfo and DBC.ServerTblOpInfo
at the same time as it archives TD_SERVER_DB.
• The post-restore script validates server connectivity.
Note the following about copying foreign server objects:
• Users lose their privileges on a foreign server object after it is copied, so administrators must grant these privileges again.
• You can copy the entire TD_SERVER_DB database or individual objects in the database.
Renaming is not allowed.
Teradata QueryGrid: Teradata Database-to-Teradata Database 49
Chapter 4 Administration of Teradata QueryGrid: Teradata Database-to-Teradata Database
Archive and Restore
50 Teradata QueryGrid: Teradata Database-to-Teradata Database
CHAPTER 5
Data Dictionary Tables and Views for Teradata
QueryGrid: Teradata Database-to-Teradata
Database
Introduction to the Data Dictionary Views and
Tables
Data Dictionary tables are reserved for system use. A few of the Data Dictionary tables contain metadata about the foreign servers defined on the Teradata Database system. These tables can be accessed only by users who have the required privileges to the tables. Access to the tables is strictly controlled to ensure that users, including system administrators, cannot modify them.
The Data Dictionary data can also be populated in Data Dictionary views. You can retrieve frequently-used data from any of the Data Dictionary tables via pre-defined views. The
Teradata database administrator determines the set of views available to a user.
The Data Dictionary views each have an equivalent X version. For example, for the ServerV view, there is also an X version of that view. The X version of the view limits the view to only those server objects to which the user selecting from the view has access. For more information about X and VX views (also referred to as Unicode views), see Data Dictionary,
B035-1092.
Notice:
To ensure that the system functions properly, do not modify or delete any Data Dictionary tables. Use the Data Dictionary views to access data in the tables to ensure that the tables are not accidentally modified or deleted.
For information about Data Dictionary Views and Tables, including X and VX views (also referred to as Unicode views), and examples of querying Data Dictionary views, see Data
Dictionary, B035-1092.
The views presented here are in alphabetical order for quick reference to the meaning of individual fields. The actual Data Dictionary tables and view fields do not appear in alphabetical order.
Displaying the View and Table Definitions
To display the view or table definitions, execute SHOW VIEW or SHOW TABLE
objectname, where objectname is the name of the view or table whose most recent SQL create
Teradata QueryGrid: Teradata Database-to-Teradata Database 51
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Data Dictionary Views text is to be reported. For details on using the SHOW VIEW or SHOW TABLE statement, see
Data Dictionary, B035-1092 or Database Administration, B035-1093.
Teradata-to-Teradata Connector Data Dictionary
Views
QryLogV
Category
Query
Database
DBC
View Column
TotalServerByteCount
View Column and Referenced Table.Column
Data Type
FLOAT
Format
----,---,---,---,--9
Referenced Table.Column
DBQLogTbl.TotalServerByteCount
Usage Notes
This DBQL view of the DBQLogTbl table reports things such as the AMP using the most
CPU, the AMP with the most I/O, or maximum amount of spool used when processing a query. It can also report the size of the data transferred between Teradata and a foreign server.
For more information about the QryLogV view, see Data Dictionary, B035-1092.
For more information about the DBQL feature and detailed descriptions about the QryLogV view, see Database Administration, B035-1093.
TotalServerByteCount Column
The TotalServerByteCount column is the total number of bytes read from or sent to foreign servers involved in the request.
QryLogStepsV
Category
Query
Database
DBC
52 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Data Dictionary Views
View Column
ServerByteCount
View Column and Referenced Table.Column
Data Type
FLOAT
Format
----,---,---,---,--9
Referenced Table.Column
DBQLStepTbl.ServerByteCount
Usage Notes
This view of the DBQLStepTbl table is populated if you specify the WITH STEPINFO option. When the query completes, the system logs one row for each query step, including parallel steps.
This view can also show the size of the data transferred between Teradata and a foreign server for each step.
For more information about the QryLogStepsV view, see Data Dictionary, B035-1092.
For more information about the DBQL feature and a description of the QryLogStepsV view, see Database Administration, B035-1093.
ServerByteCount Column
The ServerByteCount column is the total number of bytes sent to or received from a foreign server for each step.
ServerV[X]
View Column
ServerID
DataBaseName
ServerName
Category
Operations
Database
DBC
View Column and Referenced Table.Column
Data Type
BYTE(6)
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
Format
X(12)
X(128)
X(128)
X(128)
Referenced Table.Column
TVM.TVMId
Dbase.DatabaseName
TVM.TVMName
Dbase.DatabaseName
CreatorName
Teradata QueryGrid: Teradata Database-to-Teradata Database 53
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Data Dictionary Views
View Column
CreateTimeStamp
LastAlterName
LastAlterTimeStamp
AuthorizationName
AuthorizationType
Data Type
UNICODE
NOT CASESPECIFIC
NOT NULL
TIMESTAMP(0)
Format Referenced Table.Column
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
TIMESTAMP(0)
YYYY-MM-
DDBHH:MI:SS
X(128)
TVM.CreateTimeStamp
Dbase.DatabaseName
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
VARCHAR(15)
UNICODE
NOT CASESPECIFIC
YYYY-MM-
DDBHH:MI:SS
X(128)
X(15)
TVM.LastAlterTimeStamp
TVM.AuthName
TVM.AuthorizationType
Usage Notes
This Teradata QueryGrid connector Data Dictionary view provides details about the foreign servers defined in the Teradata Database system.
Possible Values of the AuthorizationType Column
S
' '
Value
T
Description
Invoker Trusted
Definer Trusted
Unknown
ServerInfoV[X]
Category
Operations
Database
DBC
54 Teradata QueryGrid: Teradata Database-to-Teradata Database
View Column
NameInfo
NVPType
ServerName
ValueInfo
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Data Dictionary Views
View Column and Referenced Table.Column
Data Type
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(7)
UNICODE
NOT CASESPECIFIC
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(32000)
UNICODE
NOT CASESPECIFIC
Format
X(128)
X(7)
X(128)
X(256)
Referenced Table.Column
ServerInfo.NameInfo
ServerInfo.NameInfoType
TVM.TVMName
ServerInfo.ValueInfo
Usage Notes
This Teradata QueryGrid connector Data Dictionary view provides details about the name value pairs used by foreign servers defined in the Teradata Database system.
Possible Values of the NVPType Column
• IMPORT
• EXPORT
• GLOBAL
• UNKNOWN
TblSrvV[X]
View Column
ServerName
Category
Operations
Database
DBC
View Column and Referenced Table.Columns
Data Type
VARCHAR(128)
Teradata QueryGrid: Teradata Database-to-Teradata Database
Format
X(128)
Referenced Table.Column
TVM.TVMName
55
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Data Dictionary Views
View Column
SrvDataBaseName
TblOpName
TblOpDBName
TableOperatorType
Data Type
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(7)
UNICODE
NOT CASESPECIFIC
Format
X(128)
X(128)
X(128)
X(7)
Referenced Table.Column
Dbase.DatabaseName
ServerTblOpInfo.TblopName
ServerTblOpInfo.TblopDBName
ServerTblOpInfo.TblOpType
Usage Considerations
This Teradata QueryGrid connector view returns information about the foreign servers and their associated table operators.
Possible Values of the TableOperatorType Column
• IMPORT
• EXPORT
• UNKNOWN
TblSrvInfoV[X]
Category
Operations
Database
DBC
56 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Data Dictionary Views
View Column
ServerName
SrvDataBaseName
TblOpName
TbpOpDataBaseName
NameInfo
ValueInfo
TableOperatorType
View Column and Referenced Table.Column
Data Type
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(128)
UNICODE
NOT CASESPECIFIC
NOT NULL
VARCHAR(32000)
UNICODE
NOT CASESPECIFIC
VARCHAR(7)
UNICODE
NOT CASESPECIFIC
Format
X(128)
X(128)
X(128)
X(128)
X(128)
X(256)
X(7)
Referenced Table.Column
TVM.TVMName
Dbase.DatabaseName
ServerTblOpInfo.TblopName
ServerTblOpInfo.TblopDBName
ServerInfo.NameInfo
ServerInfo.ValueInfo
ServerTblOpInfo.TblOpType
Usage Considerations
This Teradata QueryGrid connector view returns the name value pairs defined for a foreign server.
Possible Values of the TableOperatorType Column
• IMPORT
• EXPORT
Teradata QueryGrid: Teradata Database-to-Teradata Database 57
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
• UNKNOWN
Teradata-to-Teradata Connector Dictionary
Tables
DBC.AccessRights
This Data Dictionary table stores information about discretionary access privileges and rowlevel security privileges that have been granted.
This information includes:
• The ID of the user that was granted the privilege
• The specific privilege that was granted
• Who granted it, and whether it was granted using the GRANT statement
Row Values
Row
AccessRight
Description
The type of privilege granted on a user object only. Possible values include:
• CS (CREATE SERVER)
• DS (DROP SERVER)
Note: These values must be explicitly granted.
Related Topics
For more information about the DBC.AccessRights table, see Data Dictionary, B035-1092.
DBC.AccLogRuleTbl
This Data Dictionary table stores information about the logging of access privilege checks.
This information includes:
• Typical access control privilege checks
• Row-level security privilege checks
• The user, database, and object involved in the privilege check
Note: For Teradata QueryGrid connector queries, this is the remote object or user on the foreign server involved in the privilege check.
Row Values
Row
AcrCreateServer
Description
This row stores the logging in effect for the CREATE SERVER privilege on TD_SERVER_DB to which the rule applies.
58 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
Row
AcrDropServer
Description
This row is populated if you specify the ON FOREIGN SERVER option in the BEGIN or END LOGGING statement.
This row stores the logging in effect for the DROP SERVER privilege on TD_SERVER_DB to which the rule applies.
This row is populated if you specify the ON FOREIGN SERVER option in the BEGIN or END LOGGING statement.
DBC.DBQLogTbl
This Data Dictionary table is the main DBQL table containing information about the SQL and Teradata QueryGrid connector queries being logged.
The DBQLogTbl default row consists of all the available DBQLogTbl table fields. The default row provides general query information that is usually adequate for investigating a query that is interfering with performance.
When no options are specified, a default row includes:
• User ID and user name under which the session being logged was initiated
• Unique ID for the process, session, and host (client) connection
• Account string, expanded as appropriate, that was current when the query completed
• First 200 characters of the query statement
• CPU and I/O statistics
• Default database name that was current when the query completed
• The total size of the data transferred between Teradata and a foreign server
The default is one default row per query.
Row Values
Row
StatementGroup
Description
If there is a DDL statement in a request, the StatementGroup column reports which type:
• DDL CREATE if this is a CREATE FOREIGN SERVER statement
• DDL ALTER if this is an ALTER or DROP FOREIGN SERVER statement
• OTHER SYS OTHER if this is a SHOW FOREIGN SERVER or
HELP FOREIGN statement
• DDL GRANT
If the statement has only one DML statement or multiple DML statements that are all of the same type, StatementGroup indicates the type. For example if there are three DELETE statements in a request, StatementGroup reports:
DML DELETE
Teradata QueryGrid: Teradata Database-to-Teradata Database 59
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
Row
StatementType
TotalServerByteCount
Description
Similarly, for requests with individual or multiple INSERT,
INSERT... SELECT, UPDATE or SELECT statements,
StatementGroup reports:
• DML INSERT
• DML INSERT... SELECT
• DML UPDATE
• SELECT
In a multistatement request with different types of DML statements, you see a list showing the number of statements of each type in the request. For example, a request with one insert and two update statements appears as:
DML Del=0 Ins=1 InsSel=0 Upd=2 Sel=0
The type of statement of the query.
In a multistatement request, this is the last statement of the request.
However, this may not accurately describe the request. For more statement information, see StatementGroup.
The possible values recorded include:
• CREATE SERVER for the CREATE FOREIGN SERVER statement.
• ALTER SERVER for ALTER FOREIGN SERVER statement.
• DROP SERVER for the DROP FOREIGN SERVER statement.
• SHOW for the SHOW FOREIGN SERVER statement.
• HELP for the HELP FOREIGN statement.
The total number of bytes read from or sent to a foreign server object. The column is NULL if the request does not load or send data from or to a foreign server object.
Related Topics
For more information about the ...
DBQL feature, how to enable DBQL logging, and the DBC.DBQStepTbl table and fields
See ...
Database Administration
B035-1093
BEGIN/REPLACE QUERY LOGGING statement SQL Data Definition Language - Syntax and
Examples
B035-1144
DBC.Dependency
This Data Dictionary table stores information about the relationships and dependencies between various types of objects. The types of relationships and dependencies include:
• Relationships between tables and row-level security constraints
60 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
• Dependencies between JAR objects
• Relationships between foreign server objects and table operators
Row Value
Row
RelationshipCode
Description
The value KO indicates the relationship between the foreign server and the table operator.
DBC.ServerInfo
This Teradata QueryGrid connector Data Dictionary table stores the name value pairs of the server object that are used by the table operators to connect to the foreign server if the name value pair of the USING clause is specified in the CREATE/ALTER FOREIGN SERVER statement.
Row Values
DBC.ServerInfo Field
DatabaseID
NameInfo
NameInfoType
ServerID
ValueInfo
Description
The database ID that contains the server object.
The name attribute specified in the name value pair of the USING clause in the CREATE or ALTER
FOREIGN SERVER statement.
Possible values include:
• G indicates the server attribute name value pair defined in the USING clause of the CREATE or
ALTER FOREIGN SERVER statement.
• I indicates the IMPORT table operator name value pair defined in the USING clause of the CREATE or ALTER FOREIGN SERVER statement.
• E indicates the EXPORT table operator name value pair defined in the USING clause of the CREATE or ALTER FOREIGN SERVER statement.
The ID of the server object.
The value attribute specified in the name value pair of the USING clause in the CREATE or ALTER
FOREIGN SERVER statement.
DBC.ServerTblOpInfo
This Teradata QueryGrid connector Data Dictionary table stores information about the table operator associated with the foreign server.
This table also includes the database and table operator names to avoid issues with the object
ID changing during an archive or restore operation.
Teradata QueryGrid: Teradata Database-to-Teradata Database 61
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
Row Values
DBC.ServerTblOpInfo Field
DatabaseId
ServerID
TblOpDatabaseName
TblopName
TblOpType
Description
The database ID that contains the foreign server object.
The ID of the foreign server.
The database name in which the table operator is defined.
The name of the table operator associated with the foreign server.
Possible values include:
• I indicates the IMPORT table operator name value pair.
• E indicates the EXPORT table operator name value pair.
• 'UNKNOWN' indicates an unknown name value pair.
Note: This column may return more than one operator type.
DBC.DBQLStepTbl
This DBQL table stores information about each processing step used to satisfy the query. For a Teradata QueryGrid connector query, this includes the size of the data transferred between
Teradata and a foreign server. One row is logged for each step.
This Data Dictionary table is only populated if you specify the WITH STEPINFO option in the BEGIN or REPLACE QUERY LOGGING statement. When the query completes, the system logs one row for each query step, including parallel steps.
Row Value
Row
ServerByteCount
Description
The number of row bytes read from or sent to a foreign server object.
This column is NULL if the step does not load or send data to or from a foreign server.
Related Topics
For more information ...
For more information about the DBQL feature, how to enable DBQL logging, the
DBC.DBQStepTbl table and fields
See ...
Database Administration
B035-1093
62 Teradata QueryGrid: Teradata Database-to-Teradata Database
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
For more information ...
For more information about the BEGIN/
REPLACE QUERY LOGGING statement
See ...
SQL Data Definition Language - Syntax and
Examples
B035-1144
DBC.TVM Table
This Data Dictionary table stores one row for each of the following objects on the system:
• Column
• Database
• External stored procedure
• Hash index
• JAR
• Join index
• Macro
• Stored procedure
• Table
• Trigger
• User-defined function
• User-defined method
• User-defined type
• View
For Teradata QueryGrid connector queries, the DBC.TVM table stores one row for each foreign server object on the Teradata Database system if one of the following options is specified:
• The TRUSTED security type of the CREATE or REPLACE AUTHORIZATION statement.
• The optional comment string of the SQL COMMENT statement.
The DBC.TVM table is not archived during archive and restore operations.
Row Values
Row
AuthIdUsed
AuthName
AuthorizationSubType
Description
The authorization ID of the foreign server object.
This row returns NULL if the foreign server object is not authorized.
The name of the authorization defined for the foreign server object.
This row returns NULL if the foreign server object is not authorized.
Whether the specified authorization is the default authorization.
Possible values include:
• I indicates the specified INVOKER TRUSTED authorization.
• D indicates DEFINER TRUSTED authorization.
• F indicates DEFINER DEFAULT TRUSTED authorization.
Teradata QueryGrid: Teradata Database-to-Teradata Database 63
Chapter 5 Data Dictionary Tables and Views for Teradata QueryGrid: Teradata Database-to-Teradata Database
Teradata-to-Teradata Connector Dictionary Tables
Row
AuthorizationType
CommentString
TableKind
Description
• NULL indicates the foreign server object is not authorized.
The type of authorization of the foreign server object. Possible values include:
• T indicates that the TRUSTED security type of the CREATE or
REPLACE AUTHORIZATION statement is specified.
• NULL indicates the foreign server object is not authorized
Text or comment supplied by the user on the column, database, table, view, macro, user-defined function, user-defined types, user-defined methods, stored procedure, role, profile, user, or foreign server.
If you are using a foreign server object, this row returns K.
Note: K is supported on the Teradata QueryGrid connectors only.
For more information on TableKind values, see Data Dictionary,
B035-1092.
64 Teradata QueryGrid: Teradata Database-to-Teradata Database
APPENDIX A
Notation Conventions
About Notation Conventions
This appendix describes the notation conventions used in this book.
Convention
Syntax Diagrams
Description
Describes SQL syntax form, including options.
Square braces in the text Represent options. The indicated parentheses are required when you specify options.
For example:
DECIMAL [(n[,m])] means the decimal data type can be defined optionally:
• without specifying the precision value n or scale value m
• specifying precision (n) only
• specifying both values (n,m)
You cannot specify scale without first defining precision.
• CHARACTER [(n)] means that use of (n) is optional.
The values for n and m are integers in all cases.
Syntax Diagram Conventions
Notation Conventions
Item
Letter
Number
Word
Definition and Comments
An uppercase or lowercase alphabetic character ranging from A through Z.
A digit ranging from 0 through 9.
Do not use commas when typing a number with more than 3 digits.
Keywords and variables.
• UPPERCASE LETTERS represent a keyword.
Syntax diagrams show all keywords in uppercase, unless operating system restrictions require them to be in lowercase.
Teradata QueryGrid: Teradata Database-to-Teradata Database 65
Appendix A Notation Conventions
Syntax Diagram Conventions
Item
Spaces
Punctuation
Definition and Comments
• lowercase letters represent a keyword that you must type in lowercase, such as a Linux command.
• Mixed Case letters represent exceptions to uppercase and lowercase rules.
The exceptions are noted in the syntax explanation.
• lowercase italic letters represent a variable such as a column or table name.
Substitute the variable with a proper value.
• lowercase bold letters represent an excerpt from the diagram.
The excerpt is defined immediately following the diagram that contains it.
• UNDERLINED LETTERS represent the default value.
This applies to both uppercase and lowercase words.
Use one space between items such as keywords or variables.
Type all punctuation exactly as it appears in the diagram.
Paths
The main path along the syntax diagram begins at the left with a keyword, and proceeds, left to right, to the vertical bar, which marks the end of the diagram. Paths that do not have an arrow or a vertical bar only show portions of the syntax.
The only part of a path that reads from right to left is a loop.
Continuation Links
Paths that are too long for one line use continuation links. Continuation links are circled letters indicating the beginning and end of a link:
A
A
When you see a circled letter in a syntax diagram, go to the corresponding circled letter and continue reading.
Required Entries
Required entries appear on the main path:
SHOW
SHOW
CONTROLS
VERSIONS
If you can choose from more than one entry, the choices appear vertically, in a stack. The first entry appears on the main path:
SHOW
CONTROLS
VERSIONS
66 Teradata QueryGrid: Teradata Database-to-Teradata Database
Appendix A Notation Conventions
Syntax Diagram Conventions
Optional Entries
You may choose to include or disregard optional entries. Optional entries appear below the main path:
SHOW
CONTROLS
If you can optionally choose from more than one entry, all the choices appear below the main path:
READ
SHARE
ACCESS
Some commands and statements treat one of the optional choices as a default value. This value is UNDERLINED. It is presumed to be selected if you type the command or statement without specifying one of the options.
Strings
String literals appear in apostrophes:
'msgtext '
Abbreviations
If a keyword or a reserved word has a valid abbreviation, the unabbreviated form always appears on the main path. The shortest valid abbreviation appears beneath.
SHOW
CONTROLS
CONTROL
In the above syntax, the following formats are valid:
SHOW CONTROLS
SHOW CONTROL
Loops
A loop is an entry or a group of entries that you can repeat one or more times. Syntax diagrams show loops as a return path above the main path, over the item or items that you can repeat:
,
3
(
,
cname
4
)
Read loops from right to left.
The following conventions apply to loops:
Item
maximum number of entries allowed
Description
The number appears in a circle on the return path.
Example
In the example, you may type
cname a maximum of four times.
Teradata QueryGrid: Teradata Database-to-Teradata Database 67
Appendix A Notation Conventions
Syntax Diagram Conventions
Item
minimum number of entries allowed separator character required between entries delimiter character required around entries
Description
The number appears in a square on the return path.
The character appears on the return path.
If the diagram does not show a separator character, use one blank space.
The beginning and end characters appear outside the return path.
Generally, a space is not needed between delimiter characters and entries.
Example
In the example, you must type at least three groups of column names.
In the example, the separator character is a comma.
In the example, the delimiter characters are the left and right parentheses.
Excerpts
Sometimes a piece of a syntax phrase is too large to fit into the diagram. Such a phrase is indicated by a break in the path, marked by (|) terminators on each side of the break. The name for the excerpted piece appears between the terminators in boldface type.
The boldface excerpt name and the excerpted phrase appears immediately after the main diagram. The excerpted phrase starts and ends with a plain horizontal line:
LOCKING
excerpt
HAVING
con where_cond
excerpt
,
cname
,
col_pos
Multiple Legitimate Phrases
In a syntax diagram, it is possible for any number of phrases to be legitimate:
dbname
DATABASE
tname
TABLE
vname
VIEW
In this example, any of the following phrases are legitimate:
dbname
68 Teradata QueryGrid: Teradata Database-to-Teradata Database
Appendix A Notation Conventions
Character Shorthand Notation Used in This Book
DATABASE dbname
tname
TABLE tname
vname
VIEW vname
Sample Syntax Diagram
,
CREATE VIEW
CV
A
B
viewname cname dbname
DATABASE
tname
TABLE
SEL
VIEW
,
expr vname
FROM
,
tname
FOR
IN
.aname
AS
LOCKING
LOCK
ACCESS
SHARE
READ
WRITE
EXCLUSIVE
EXCL
MODE
qual_cond
C
HAVING cond
qual_cond
;
A
B
C
WHERE cond
GROUP BY
,
cname
,
col_pos
Character Shorthand Notation Used in This Book
This book uses the Unicode naming convention for characters. For example, the lowercase character ‘a’ is more formally specified as either LATIN CAPITAL LETTER A or U+0041.
The U+xxxx notation refers to a particular code point in the Unicode standard, where xxxx stands for the hexadecimal representation of the 16-bit value defined in the standard.
In parts of the book, it is convenient to use a symbol to represent a special character, or a particular class of characters. This is particularly true in discussion of the following Japanese character encodings:
• KanjiEBCDIC
• KanjiEUC
• KanjiShift-JIS
These encodings are further defined in International Character Set Support.
Teradata QueryGrid: Teradata Database-to-Teradata Database 69
Appendix A Notation Conventions
Character Shorthand Notation Used in This Book
Character Symbols
The symbols, along with character sets with which they are used, are defined in the following table.
a-z
A-Z
0-9
<
Symbol
a-z
A-Z
0-9
Encoding
Any
Any
Meaning
Any single byte Latin letter or digit.
Any fullwidth Latin letter or digit.
I
>
T
Δ
Δ ss
2 ss
3
KanjiEBCDIC Shift Out [SO] (0x0E).
Indicates transition from single to multibyte character in
KanjiEBCDIC.
KanjiEBCDIC Shift In [SI] (0x0F).
Indicates transition from multibyte to single byte KanjiEBCDIC.
Any
Any
Any multibyte character.
The encoding depends on the current character set.
For KanjiEUC, code set 3 characters are always preceded by ss3
.
Any single byte Hankaku Katakana character.
In KanjiEUC, it must be preceded by multibyte character.
ss2
, forming an individual
Any Represents the graphic pad character.
Any
KanjiEUC
KanjiEUC
Represents a single or multibyte pad character, depending on context.
Represents the EUC code set 2 introducer (0x8E).
Represents the EUC code set 3 introducer (0x8F).
For example, string “TEST”, where each letter is intended to be a fullwidth character, is written as TEST. Occasionally, when encoding is important, hexadecimal representation is used.
For example, the following mixed single byte/multibyte character data in KanjiEBCDIC character set
LMN<TEST>QRS is represented as:
D3 D4 D5 0E 42E3 42C5 42E2 42E3 0F D8 D9 E2
Pad Characters
The following table lists the pad characters for the various character data types.
70 Teradata QueryGrid: Teradata Database-to-Teradata Database
Server Character Set
LATIN
UNICODE
GRAPHIC
KANJISJIS
KANJI1
Appendix A Notation Conventions
Character Shorthand Notation Used in This Book
Pad Character Name
SPACE
SPACE
IDEOGRAPHIC SPACE
ASCII SPACE
ASCII SPACE
Pad Character Value
0x20
U+0020
U+3000
0x20
0x20
Teradata QueryGrid: Teradata Database-to-Teradata Database 71
Appendix A Notation Conventions
Character Shorthand Notation Used in This Book
72 Teradata QueryGrid: Teradata Database-to-Teradata Database
Λήψη
Δημόσιος σύνδεσμος ενημερώθηκε
Ο δημόσιος σύνδεσμος για τη συνομιλία σας ενημερώθηκε. You may view and manage your chat links after registration here.
Δημόσιος σύνδεσμος εγγράφου
Διαφήμιση
