Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Mon, 14 Jul 2003 @ 22:10:04 GMT


     
  <Prev Next>   <<First <Prev Next> Last>>  


Subj:   Re: Selecting the COPn
 
From:   Heying, Jerold G

Kumaran,

Answers based on my own experience...

A1. A random pick from the COPn entries that your client machine knows about.

A2. There is a timeout and then another COPy is tried

A3. The COPn determination is always a random pick for ODBC, JDBC, or CLI. The difference is whether the list to pick from is generated dynamically at the time of the connection, or statically. ODBC will cache the list in the registry at the time the DSN entry is created, the default, unless you click the DSN box that says, "Do not resolve alias name to IP address." So, ODBC generally has a static list to pick from. CLI generates the list dynamically. The Type 2 and 3 JDBC drivers used CLI, so they created the COP list dynamically. I assume that the Type 4 also creates a dynamic list of COP entries to pick from.

Here is more detail on this subject, again, my understanding based only on experience...

.logon TDPID/user,password

Any CLI based utility will dynamically generate a set of cop names at the time you try to make a connection.

* The TCP/IP call gethostbyname is used to resolve these names, by appending cop1, cop2, etc to the TDPID.

* gethostbyname will behave according to the name resolution rules of the platform. On MPRAS you can specify the order of resolution in the file /etc/netconfig. On Windows I think the order is fixed (hosts, then DNS, then WINS).

* The algorithm will continue to resolve cop names until it hits a value that fails. If you have a four node system with an Ethernet interface on each node, you would define an alias for each node that was TDPIDcop1, TDPIDcop2, TDPIDcop3, TDPIDcop4. So a list of 4 cop entries would be generated for a logon request and then the algorithm just picks one of the 4 at random. Let's say you had a 64 node system and wanted a Ethernet interface on each node to accept client traffic. If you forgot to put TDPIDcop5 in the DNS, then the algorithm would fail trying to resolve that and would never even look for TPDIDcop6 - TDPIDcop64.

* If you do not specify TDPID, then the CLI software is supposed to look in the file clispb.dat for the default TDPID, which is normally "dbc."

* Where you put these cop entries for address resolution is up to you. Most people use DNS, since it is a central repository. You must understand the order of resolution on the platform you use. If gethostbyname looks in the hosts file first on your platform, it will not look to DNS if it could resolve successfully from hosts. That is most likely what you are running into - junk that you need to clean up on your hosts file. Testing connections from multiple machines helps to isolate these issues too.

* You can use this knowledge for trouble shooting LAN connections to Teradata. Are all of the nodes accepting client requests successfully? You can make up a new cop name, such as MYTDPID and test individual IP addresses by putting an entry in the hosts file on you desktop machine, MYTDPIDcop1. Now you are sure that a logon to MYTDPID went to a specific node of your Teradata system.

ODBC requires you to create a DSN entry that specifies the machine to connect to, etc. When you create the DSN entry you can give the TDPID and it will resolve the cop names as they exist at that time and cache them in the registry. This is an ODBC thing, not a Teradata thing. There is an option on our screen to create the DSN that says do NOT resolve. In that case ODBC will behave like CLI by dynamically generating the list of cops to choose from when you make a connection.

One interesting thing about Windows gethostbyname that I learned at my customer site (part of that trial by fire): Windows name resolution is very fast for known IP addresses. However if the address cannot be resolved there is an escalation through the sources I mentioned...hosts...DNS...WINS. So trying to resolve an invalid address can take a long time on some networks (15-60+ seconds). Since our algorithm for generating the list of cops is terminated by the first invalid address this can be an issue for an application that want to do a quick logon, request, logoff - such as the old Web CGI architecture. Engineering has put a workaround in the CLI logic on Windows where you can give a hint for how many valid cops there are. You set an environment variable to tell CLI when to stop.

TDPID=4

Having this ENV set on your Windows platform for the above CLI logon will tell the client software NOT to issue a gethostbyname call for TPDIDcop5. Just do it for cop1-4 to avoid requesting one that is not valid and taking a long time to return.

Jerry Heying
Teradata Solution Architect



     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023