Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Teradata QueryGrid: Teradata Database-to
Document related concepts
Microsoft Access wikipedia , lookup
Oracle Database wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Team Foundation Server wikipedia , lookup
Concurrency control wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Relational model wikipedia , lookup
Clusterpoint wikipedia , lookup
ContactPoint wikipedia , lookup
Transcript
What would you do if you knew?™ Teradata QueryGrid Teradata QueryGrid: Teradata Database-toTeradata 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 Description Teradata QueryGrid: Teradata-to-Teradata 15.00.01 • January 2016 • • • 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 Description • Teradata QueryGrid: Teradata-to-Teradata 15.0 Updated the EXPLAIN text for SELECT queries, updated Limitations section. Initial publication. January 2015 Additional Information URL Description www.info.teradata.com 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]. 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 4 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 Privileges Needed to Use Teradata QueryGrid. 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 CREATE FOREIGN SERVER. 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 Transaction semantics are not supported between Teradata systems. For example, suppose that the following statements are executed in this order: 1. BEGIN Transaction ; 2. INSERT INTO t1@remote SELECT * FROM local 3. INSERT INTO local values (1,2) 4. 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 A EXTERNAL SECURITY INVOKER TRUSTED authorization_name DEFINER A , ADD modify options DROP drop options ; 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 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-toTeradata 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: 12 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 WITH TEXT DENIALS FIRST LAST FIRST AND LAST EACH A FOR CONSTRAINT constraint_name ALL , operation GRANT B , BY database_name user_name B , ON ; 20 AUTHORIZATION authorization_name DATABASE database_name USER database_name TABLE object_name VIEW database_name. MACRO user_name. PROCEDURE FUNCTION TYPE FOREIGN SERVER 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. 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 object_name database_name. user_name. 'comment' ; AS IS 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 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. 16 Teradata QueryGrid: Teradata Database-to-Teradata Database 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 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 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. Syntax CREATE FOREIGN SERVER server_name A EXTERNAL SECURITY TRUSTED authorization_name TD_SERVER_DB. A using option DO IMPORT WITH DO EXPORT WITH ; operator option , DO EXPORT WITH operator option , DO IMPORT WITH operator option 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-toTeradata 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 ON END LOGGING DENIALS ALL , WITH TEXT A operation GRANT A B FOR CONSTRAINT , constraint_name BY database_name user_name B , ON ; 20 AUTHORIZATION authorization_name DATABASE database_name USER database_name TABLE object_name VIEW database_name. MACRO user_name. PROCEDURE FUNCTION TYPE FOREIGN SERVER 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 -----------------------------Customer_Order Inventory Item_Price NewItems Orders PriceList Kind ---T T T T T T Comment -----------? ? ? ? ? ? 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 -----------------------------item_no item_price Type ---I D Comment -----------? ? 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 IN XML server_name 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 ----------2503 2504 item_price -----------7.50 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 ----------2503 2501 2504 2502 item_desc -------------------Oil Filter, M52 Air Cleaner, E46 Oil Filter, M60 Air Cleaner, E60 inventory_value ----------------120.00 139.95 17.50 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 ----------10002 10001 10001 10003 item_no ----------2501 2502 2501 2501 item_value ----------------139.95 174.95 279.90 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 ----------2502 36 item_price -----------34.99 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 2501 2503 8.75 27.99 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 ----------2502 2504 2501 2503 item_value ----------------419.88 17.50 139.95 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 Option. 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 Privileges that you must have Create a foreign server object. • • Drop a foreign server object. DROP SERVER privilege on TD_SERVER_DB or on the server object. Modify a foreign server object. • • Create or replace an authorization object. 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. 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 CREATE FOREIGN SERVER. • 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: JVMOptions: -XX:IpRange=192.0.2.24 Name the file itjvmopt.txt and put it in the following location: /etc/opt/teradata/tdconfig/jvmconfig/ 2 Run the following command: cufconfig –f /etc/opt/teradata/tdconfig/jvmconfig/jvmopt.txt 3 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 and Referenced Table.Column View Column Data Type Format Referenced Table.Column TotalServerByteCount FLOAT ----,---,---,---,--9 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 and Referenced Table.Column View Column Data Type Format Referenced Table.Column ServerByteCount FLOAT ----,---,---,---,--9 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] Category Operations Database DBC View Column and Referenced Table.Column View Column Data Type Format Referenced Table.Column ServerID BYTE(6) X(12) TVM.TVMId X(128) Dbase.DatabaseName X(128) TVM.TVMName X(128) Dbase.DatabaseName NOT NULL DataBaseName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL ServerName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL CreatorName VARCHAR(128) 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 Data Type Format Referenced Table.Column UNICODE NOT CASESPECIFIC NOT NULL CreateTimeStamp TIMESTAMP(0) YYYY-MMDDBHH:MI:SS TVM.CreateTimeStamp LastAlterName VARCHAR(128) X(128) Dbase.DatabaseName UNICODE NOT CASESPECIFIC NOT NULL LastAlterTimeStamp TIMESTAMP(0) YYYY-MMDDBHH:MI:SS TVM.LastAlterTimeStamp AuthorizationName VARCHAR(128) X(128) TVM.AuthName X(15) TVM.AuthorizationType UNICODE NOT CASESPECIFIC AuthorizationType VARCHAR(15) UNICODE NOT CASESPECIFIC 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 Value Description T Invoker Trusted S Definer Trusted '' Unknown ServerInfoV[X] Category Operations Database DBC 54 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 and Referenced Table.Column View Column Data Type Format Referenced Table.Column NameInfo VARCHAR(128) X(128) ServerInfo.NameInfo X(7) ServerInfo.NameInfoType X(128) TVM.TVMName X(256) ServerInfo.ValueInfo UNICODE NOT CASESPECIFIC NOT NULL NVPType VARCHAR(7) UNICODE NOT CASESPECIFIC ServerName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL ValueInfo VARCHAR(32000) UNICODE NOT CASESPECIFIC 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] Category Operations Database DBC View Column and Referenced Table.Columns View Column Data Type Format Referenced Table.Column ServerName VARCHAR(128) X(128) TVM.TVMName Teradata QueryGrid: Teradata Database-to-Teradata Database 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 Data Type Format Referenced Table.Column X(128) Dbase.DatabaseName X(128) ServerTblOpInfo.TblopName X(128) ServerTblOpInfo.TblopDBName X(7) ServerTblOpInfo.TblOpType UNICODE NOT CASESPECIFIC NOT NULL SrvDataBaseName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL TblOpName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL TblOpDBName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL TableOperatorType VARCHAR(7) UNICODE NOT CASESPECIFIC 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 and Referenced Table.Column View Column Data Type Format Referenced Table.Column ServerName VARCHAR(128) X(128) TVM.TVMName X(128) Dbase.DatabaseName X(128) ServerTblOpInfo.TblopName X(128) ServerTblOpInfo.TblopDBName X(128) ServerInfo.NameInfo X(256) ServerInfo.ValueInfo X(7) ServerTblOpInfo.TblOpType UNICODE NOT CASESPECIFIC NOT NULL SrvDataBaseName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL TblOpName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL TbpOpDataBaseName VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL NameInfo VARCHAR(128) UNICODE NOT CASESPECIFIC NOT NULL ValueInfo VARCHAR(32000) UNICODE NOT CASESPECIFIC TableOperatorType VARCHAR(7) UNICODE NOT CASESPECIFIC 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 Description AccessRight 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 58 Row Description AcrCreateServer This row stores the logging in effect for the CREATE SERVER privilege on TD_SERVER_DB to which the rule applies. 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 Description This row is populated if you specify the ON FOREIGN SERVER option in the BEGIN or END LOGGING statement. AcrDropServer 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 Description StatementGroup 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 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 StatementType 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. TotalServerByteCount 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 ... See ... DBQL feature, how to enable DBQL logging, and Database Administration the DBC.DBQStepTbl table and fields 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 Description RelationshipCode 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 Description DatabaseID The database ID that contains the server object. NameInfo The name attribute specified in the name value pair of the USING clause in the CREATE or ALTER FOREIGN SERVER statement. NameInfoType 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. ServerID The ID of the server object. ValueInfo 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 Description DatabaseId The database ID that contains the foreign server object. ServerID The ID of the foreign server. TblOpDatabaseName The database name in which the table operator is defined. TblopName The name of the table operator associated with the foreign server. TblOpType 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 Description ServerByteCount 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 62 For more information ... See ... For more information about the DBQL feature, how to enable DBQL logging, the DBC.DBQStepTbl table and fields Database Administration B035-1093 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 ... See ... For more information about the BEGIN/ REPLACE QUERY LOGGING statement 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 Description AuthIdUsed The authorization ID of the foreign server object. This row returns NULL if the foreign server object is not authorized. AuthName The name of the authorization defined for the foreign server object. This row returns NULL if the foreign server object is not authorized. AuthorizationSubType 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 Description • NULL indicates the foreign server object is not authorized. AuthorizationType 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 CommentString 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. TableKind 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 Description Syntax Diagrams 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 Definition and Comments Letter An uppercase or lowercase alphabetic character ranging from A through Z. Number A digit ranging from 0 through 9. Do not use commas when typing a number with more than 3 digits. Word 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 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. Spaces Use one space between items such as keywords or variables. Punctuation 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 4 cname ) Read loops from right to left. The following conventions apply to loops: Item Description Example maximum number of entries allowed The number appears in a circle on the return path. 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 Description Example minimum number of entries allowed The number appears in a square on the return path. In the example, you must type at least three groups of column names. separator character required between entries The character appears on the return path. In the example, the separator character is a comma. If the diagram does not show a separator character, use one blank space. delimiter character required around entries The beginning and end In the example, the delimiter characters appear outside the characters are the left and right return path. parentheses. Generally, a space is not needed between delimiter characters and entries. 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 excerpt where_cond , 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 viewname AS A cname CV LOCKING LOCK ACCESS dbname A DATABASE FOR SHARE IN tname READ TABLE WRITE EXCLUSIVE vname VIEW EXCL , B SEL B MODE expr , FROM qual_cond tname C .aname C HAVING cond ; qual_cond , 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. Symbol Encoding Meaning a-z A-Z 0-9 Any Any single byte Latin letter or digit. a-z A-Z 0-9 Any Any fullwidth Latin letter or digit. < 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. T Any Any multibyte character. The encoding depends on the current character set. For KanjiEUC, code set 3 characters are always preceded by ss3. I Any Any single byte Hankaku Katakana character. In KanjiEUC, it must be preceded by ss2, forming an individual multibyte character. Δ Any Represents the graphic pad character. Δ Any Represents a single or multibyte pad character, depending on context. ss2 KanjiEUC Represents the EUC code set 2 introducer (0x8E). ss3 KanjiEUC 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 Appendix A Notation Conventions Character Shorthand Notation Used in This Book Server Character Set Pad Character Name Pad Character Value LATIN SPACE 0x20 UNICODE SPACE U+0020 GRAPHIC IDEOGRAPHIC SPACE U+3000 KANJISJIS ASCII SPACE 0x20 KANJI1 ASCII SPACE 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
