The .NET Data Provider for Teradata must resolve a DataSource name to an IP address in order to connect to the Teradata Database. Domain Name System (DNS) is used to translate / resolve a host name to IP addresses. The Data Provider supports the following DataSource naming conventions:
COP Entries in DNS: .NET Data Provider for Teradata will attempt to resolve IP addresses using the DataSource and an incremental "cop" suffix. For example .NET Data Provider will lookup "salescop1" and "salescop2" in DNS when DataSource is set to "sales". Usually "salescop1" corresponds to node number 1 and "salescop2" corresponds to node number 2. If the DataSource value contains a fully qualified name with a domain component, e.g. sales.acmecorp.com, the Data Provider will attempt to resolve IP addresses using the hostname, an incremental "cop" suffix and the domain name, e.g. "salescop1.acmecorp.com" and "salescop2.acmecorp.com".
No COP Entries in DNS: .NET Data Provider for Teradata will attempt to resolve DataSource value to IP addresses. For example .NET Data Provider will lookup "sales" (no COP suffix) in DNS. DNS can return one or more IP addresses corresponding to the Teradata Database nodes.
IP Address Literal: .NET Data Provider will use the IP address specified as the DataSource.
Applications can utilize DataSourceDnsEntries property to control and optimize the IP-Address resolution process.
The DataSourceDnsEntries connection-string property provides a hint to the .NET Data Provider for Teradata regarding how many entries are defined in DNS for the DataSource. This property controls how the .NET Data Provider for Teradata resolves DataSource names to IP addresses. The DataSourceDnsEntries property is considered to be undefined when an application does not explicitly set this property.
Best Practice Recommendation: DataSource should be set to a fully qualified domain name (FQDN), for example "sales.acmecorp.com", to disable NetBIOS lookup. DNS might take some time to return an error for an invalid hostname. DNS performance is further exasperated when NetBIOS over TCP/IP is turned on.
This indicates that DNS does not contain "cop" entries for the DataSource. The DataSource value will be resolved to IP addresses. No attempt will be made to resolve using a "cop" suffix. Each resolution will result in a call to DNS to resolve the DataSource name. This behavior can be desirable in an environment utilizing DNS Load Balancing. When DNS is used for load balancing, administrators can configure DNS to provide a different IP address each time the DataSource name is resolved using DNS.
The .NET Data Provider for Teradata will try to determine if DNS contains "cop" entries for the DataSource. The Data Provider starts with COP1, which is appended to the DataSource value, followed by COP2, COP3, ... COPn until DNS returns an error (i.e. Host Not Found). The first entry that is not found in DNS marks the last DNS entry for the DataSource. At this point the number of DNS Entries is known (i.e. n - 1) and the remaining process is identical to DataSourceDnsEntries=value described below. If an entry for "cop1" is not defined in DNS, then resolution is disabled similar to setting DataSourceDnsEntries=0.
There are some drawbacks to leaving the DataSourceDnsEntries value undefined. A DNS resolution must fail in order for the .NET Data Provider for Teradata to discover the last entry in the sequence. DNS resolutions which result in a HostNotFound error condition are time consuming. In a multithreaded environment making multiple connections at once, only one thread can discover the last DNS entry, therefore, threads are queued while entries are being resolved. Once all the entries have been discovered, the performance of this approach is similar to using DataSourceDnsEntries=value. If additional entries are added to DNS at a later time, they will be discovered by the .NET Data Provider for Teradata when the application is restarted and begins creating a new list of addresses for the DataSource.
This indicates that DNS contains "cop" entries for the DataSource and the last "cop" entry is value. The first connection attempt will chose a random number between 1 and value. Each subsequent resolution will then increment to the next number. When the maximum number of nodes has been reached, the cycle is started again with "cop1". This approach allows for a random distribution across the nodes and the application will not encounter costly DNS resolution failures. However, if additional entries are added to DNS at a later time they will not be discovered by the .NET Data Provider for Teradata unless the supplied value is increased.