Troubleshooting

This chapter provides information for troubleshooting the following operating system and client software problems associated with Teradata JDBC Driver installation:

Note:  In troubleshooting an installation, note that:

Numeric Data Truncation

Teradata Database V2R6.2 introduced support for the SQL data type BIGINT (64-bit integer) and introduced the Large Decimal feature, which expands the maximum precision for the DECIMAL data type to DECIMAL(38). Teradata Database V2R6.1 and earlier releases are limited to a maximum precision of DECIMAL(18).

Maximum precision varies by Teradata Database release. This affects how numeric data is handled in the Teradata JDBC Driver. If Large Decimal is not supported, the maximum precision for BigDecimal is 18. If Large Decimal is supported, the maximum precision value is 38.

The Teradata JDBC Driver modification allows the PreparedStatement.setBigDecimal method to throw a DataTruncation exception for BigDecimal values that have precision values greater than the maximum precision.

When the PreparedStatement setBigDecimal method is used to bind multiple values to a parameter, the Teradata JDBC Driver determines the largest number of integral digits bound to the parameter, and then the fractional digits for each of the values is rounded as necessary to fit within the Teradata Database limit of maximum precision for a DECIMAL value. The method PreparedStatement.setLong in the Teradata JDBC Driver throws a DataTruncation exception if the maximum precision value is greater than 18 and the SQL data type BIGINT is not supported for the current database.

Character Export Width

Retrieving fixed character fields (for example, C01 CHAR(10)) utilizing the UTF8 session character set might result in padded strings. This is due to the database export factor utilized when translating characters to the session character set.

The recommended workaround is to cast the char field to a varchar.

For example:

Transaction Isolation, Concurrency, and Deadlock

Create and Drop

The following error may be seen when creating or dropping a database object, such as a table or stored procedure. It will include an error code of 2631 and an SQL state of “40001”, which indicates that this is a retryable error:

com.teradata.jdbc.jdbc_4.util.JDBCException:[Teradata Database]: Transaction ABORTed due to deadlock.

If this error occurs, the application can choose to wait a short time and then resubmit the failed create or drop operation.

JDBC FastLoad

The following error may be seen when using JDBC FastLoad and calling a PreparedStatement setter method. It will include an error code of 2631 and an SQL state of “40001”, which indicates that this is a retryable error:

com.teradata.jdbc.jdbc_4.util.JDBCException:[Teradata Database]: Transaction ABORTed due to deadlock

If this error occurs, the application can choose to wait a short time and then call the PreparedStatement setter method again. Note that error 2631 may be in a chain of exceptions; it therefore is necessary to walk down the chain of exceptions to get to error 2631.

Transaction Isolation

A potential deadlock condition can occur with two separate applications, or a single application using two threads, with each thread or application having its own JDBC connection to the Teradata Database.

The problem occurs when one connection is inserting data into a table, while the other connection is attempting to read data from the same table.

When using the default transaction isolation level of TRANSACTION_SERIALIZABLE, the following error may be seen on the thread or application that is reading from the table, approximately 2 to 5 minutes after the situation occurs. It includes an error code of 2631.

com.teradata.jdbc.jdbc_4.util.JDBCException:[Teradata Database]: Transaction ABORTed due to deadlock.

If this error occurs, either:

Large Object Interface

Description

The LOB data type categories for the Teradata Database include BLOB (binary data) and CLOB (character data). The Teradata JDBC Driver supports both data types for the Type 4 driver.

Number of LOB Columns

In the database, up to 32 LOB columns can be defined in a table. BLOBs and CLOBs closely resemble the VARBYTE and VARCHAR data types.

LOB Size Limits

LOB values up to 2 GB in size are supported. For a result set containing LOB columns, the Teradata Database transmits LOB locators to the Teradata JDBC Driver, so only the LOB locators (not the LOB values) are counted towards the Teradata Database's limit on ResultSet row size. The application can retrieve Blob or Clob objects from a ResultSet and subsequently insert those Blob or Clob objects into another table. Because LOB locators are transmitted between the Teradata Database and the Teradata JDBC Driver, this process avoids transmitting potentially large LOB values back and forth over the network.

Response Limit Exceeded Error

The most likely cause of the following error from the Teradata Database is that the application is not properly closing ResultSet objects and Statement objects.

SQLState: HY000

Message: [Teradata Database] : Response limit exceeded.

Vendor:    3130

This error message refers to the response from an SQL request, which is the output from a single-statement SQL request or a multi-statement SQL request.

The response limit is a limit imposed by the Teradata Database of a maximum of 16 open responses per connection.

To solve this issue, examine applications to verify that they have proper exception handling, with finally blocks coded to ensure that ResultSet objects, Statement objects, LOB InputStream, and LOB Reader objects are always closed as soon as they are no longer needed. If the application modifies LOBs, then Blob and Clob objects must be freed in finally blocks.

Beginning with Teradata JDBC Driver 14.00.00.28, result set holdability CLOSE_CURSORS_AT_COMMIT is supported. A "holdable" result set stays open across a commit, and is the default behavior provided by the Teradata JDBC Driver. If the application does not need holdable result sets, then the application can specify CLOSE_CURSORS_AT_COMMIT holdability, so that the Teradata JDBC Driver automatically closes result sets when an auto-commit or an explicit commit occurs. Refer to the Connection.setHoldability method for more information.

The application cannot rely on garbage collection to close ResultSet objects, Statement objects, LOB InputStream, and LOB Reader objects, since the Java programming language does not guarantee the timeliness of garbage collection. The FINALIZE_AUTO_CLOSE connection parameter is available beginning with Teradata JDBC Driver version 14.00.00.08. The FINALIZE_AUTO_CLOSE connection parameter controls the Teradata JDBC Driver's behavior during garbage collection. For more information, see Making a Teradata Database Connection.

Beginning with Teradata JDBC Driver version 14.00.00.08, if the LOG=INFO connection parameter is specified, then the Teradata JDBC Driver will log information about all outstanding open responses when a Teradata Database Error 3130 occurs. The logged information will include each open response's request number, date/time of submission, submitter thread ID, SQL request text, and submitter call stack. This information can be useful to an application developer to help pinpoint which places in the application are submitting SQL requests and not subsequently closing them.

...
2011-12-21.08:56:41.701 TERAJDBC4 INFO [Thread-8] com.teradata.jdbc.jdk6.JDK6_SQL_Connection@17757ad Response limit exceeded. Open response 11 of 16 is request number 154 submitted 2011-12-21.08:56:40.562 by [Thread-8]
SELECT * FROM MyTable ORDER BY 1
at com.teradata.jdbc.jdbc_4.ResponseTracker.notifyReceiveResponse(ResponseTracker.java:64)
at com.teradata.jdbc.jdbc_4.statemachine.StatementReceiveState.action(StatementReceiveState.java:168)
at com.teradata.jdbc.jdbc_4.statemachine.StatementController.runBody(StatementController.java:121)
at com.teradata.jdbc.jdbc_4.statemachine.StatementController.run(StatementController.java:112)
at com.teradata.jdbc.jdbc_4.TDStatement.executeStatement(TDStatement.java:373)
at com.teradata.jdbc.jdbc_4.TDStatement.executeStatement(TDStatement.java:315)
at com.teradata.jdbc.jdbc_4.TDStatement.doNonPrepExecuteQuery(TDStatement.java:303)
at com.teradata.jdbc.jdbc_4.TDStatement.executeQuery(TDStatement.java:1067)
at ...

Sometimes it is not possible to modify applications that do not properly close ResultSet objects and Statement objects; for example, if the application is a third-party application and the source code is not available.

If the application does not use LOBs, and the application does not use Scrollable Result Sets, and the application does not use Updatable ResultSets, and the application requires more than 16 open responses per connection, then the connection parameter LOB_SUPPORT=OFF can be used as a workaround. For more information about the LOB_SUPPORT connection parameter, see Making a Teradata Database Connection.

The Teradata Database transmits ResultSet LOB columns to the Teradata JDBC Driver as LOB locators. The Teradata Database requires use of the KeepResponse mode in conjunction with LOB locators.

When KeepResponse mode is not used, the Teradata Database automatically closes a response when the response:

When connection parameter LOB_SUPPORT=OFF is specified, the Teradata JDBC Driver does not use the KeepResponse mode, which means that LOBs cannot be used. This also means that the Teradata Database automatically closes responses in the two situations listed above, helping an application to avoid reaching the Teradata Database limit of 16 open responses per connection.

When connection parameter LOB_SUPPORT=OFF is specified, Scrollable Result Sets and Updatable Result Sets cannot be used. Requesting a Scrollable Result Set and/or Updatable Result Set throws an exception due to a Teradata Database error:

[Teradata Database] : Parcel kind or ordering is invalid.

When connection parameter LOB_SUPPORT=OFF is specified, the Teradata JDBC Driver does not use the KeepResponse mode; and therefore, the Teradata Database's Merge Prefetch feature may ignore the value specified with the Statement.setFetchSize method and/or the ResultSet.setFetchSize method.

Checking the Environment Parameters

CLASSPATH

If you receive a ClassNotFoundException for “com.teradata.jdbc.TeraDriver”, then the problem may be due to the classpath not being set, or the classpath being set incorrectly, such that terajdbc4.jar cannot be found. The terajdbc4.jar file must be listed on the classpath.

If you receive a “UserFile parameter null” error, then the problem might be due to the classpath not being set, or the classpath being set incorrectly such that tdgssconfig.jar cannot be found. The tdgssconfig.jar file must be listed on the classpath.

If you receive one of the following exceptions:

then the problem may be due to the classpath not being set, or the classpath being set incorrectly, such that tdgssconfig.jar cannot be found.

There are many places where the classpath can be set, including, but not limited to:

No matter where or how you set the classpath, the classpath used for the Teradata JDBC Driver must include:

Troubleshooting COP Discovery

DNS and Hosts File Entries

Check the following entries in DNS or the /etc/hosts file:

Improving Performance

If the performance of the application seems very slow, here are some recommendations for improvement:

Java HotSpot Server Virtual Machine Error on Linux Platform

Sun Java HotSpot 64-Bit Server Virtual Machine Error on Linux Red Hat Advanced Server 2.1/3.0 Itanium Platform:

Java HotSpot JVM error (HotSpot Virtual Machine Error ID: 4E4154495645294E53543F494116140E435050006F) has been observed on Linux Red Hat Advanced Server 2.1/3.0 Itanium platform when running some client applications with Teradata DBS V2R6 using Teradata JDBC Driver 3.2.

System configurations:

This HotSpot JVM error on Linux RedHat Advanced Server 2.1/3.0 Itanium platform has been reported to Sun Microsystem Bug report system, and is currently being reviewed by Sun Microsystems (Incident Review ID: 311761).

Troubleshooting Security

UserId, Password, or Account is Invalid

Error Message: [Teradata Database] : The UserId, Password or Account is invalid.

Error Code: 8017

This exception typically occurs due to invalid user, password, or account information; however, this exception can also occur in the following situations.

Cause

LOGMECH=LDAP is specified, and the username/password credentials are redundantly provided in the both LOGDATA and as separate connection parameters.

Solution

Identify LDAP users via LOGDATA, or via separate username/password parameters, but not both simultaneously.

Cause

One of the EBCDIC-variant session character sets is specified, with Teradata Database in Japanese Language Support mode, and the UserID, Password, or Account is in the Kanji character set.

Solution

Specify a non-EDCDIC-variant session character set when the UserID, Password, or Account is in the Kanji character set.

Troubleshooting Kerberos

If you have trouble getting Kerberos to work properly, check the following tables for messages and solutions to common errors.

Error Message

GSS Exception: No valid credentials provided

(Mechanism level: Failed to find any Kerberos Ticket)

Cause

“kinit” was never run.

Solution

Run the “kinit” program that resides in the “jre/bin” directory of your Java JDK.

Error Message

java.lang.SecurityException: Unable to locate a login configuration

Cause

Failed to specify a configuration file.

Solution

Specify the configuration file by using the JVM option -Djava.security.auth.login.config or by modifying the appropriate “java.security” file. The steps to do this are outlined in Meeting Kerberos Prerequisites.

Error Message

javax.security.auth.login.Login Exception: No Login Modules configured for com.sun.security.jgss.initiate

Cause

The following information is missing or misspelled in you configuration information:

com.sun.security.jgss.initiate

{

  com.sun.security.auth.module.Krb5LoginModule sufficient useTicketCache=true; 

};

Solution

Ensure that the above information is present in your Login Configuration Information. See Meeting Kerberos Prerequisites for information on setting Login Configuration.

Error Message

javax.security.auth.login.LoginException: Pre-authentication information was invalid

Cause

One of:

  • Configuration file in “C:\winnt” is bad....
  • Invalid Username was used.
  • Invalid Password was used

Solution

Validate the configuration file in c:/winnt Validate Username and Password used. Note that the username must be types in “exactly” as it appears in Windows “Active Directory Users”.

Error Message

[Teradata Database]: Invalid password

Cause

This can occur when using Kerberos Single Sign-On when

  • the Teradata Database user was not defined with the same password as their System logon password
  • the Teradata Database user was not configured to use SSO

Solution

Ensure that the same password is being used for both system logon and for the Teradata Database user password. This can be done by logging on without Kerberos with the username and password. If that isn’t the cause, then the Teradata Database user needs to be configured for SSO via the “grant logon with null password” command by a Teradata Database administrator.

Error Message

GSSException: No valid credentials provided

(Mechanism level: Failed to find any Kerberos Ticket)

Cause

Did not specify -Djavax.security.auth.useSubjectCredsOnly=false

Solution

Add the -Djavax.security.auth.useSubjectCredsOnly=false to the script that runs your application.

Error Message

KrbException: Invalid option setting in ticket request. (101)

(Mechanism level: Failed to find any Kerberos Ticket)

Cause

kinit was not run using the "-f" or forwardable option.

Solution

Run the "kinit" program that resides in the "jre/bin" directory of the Java JDK with the forwardable option set. For example, "kinit -f"

Error Message

GSSException: Invalid name provided (Mechanism level: Could not load configuration file C:\Documents and Settings\Administrator\WINDOWS\krb5.ini (The system can not find the file specified))

Cause

When using Microsoft Windows and "Terminal Services" is enabled, the locations where the krb5.ini file is seached can change.

Solution

If you wish to keep the krb5.ini file in c:\winnt, add the following to the command line that runs your Java program

-Djava.security.krb5.conf=C:/WINNT/krb5.ini

Otherwise set -Djava.security.krb5.conf to whatever location holds the krb5.ini file

Error Message

GSSException: Defective token detected (Mechanism level: AP_REP token id does not match!)

Cause

This can be due to computer clock synchronization problems. The default value for allowable clock skew is normally 5 minutes.

Solution

Check the system time on the involved systems. Synchronize the time on those systems.

LDAP Authentication Not Supported on z/OS

LDAP does not support Teradata JDBC Driver logon from z/OS.

An attempt to log on using the LDAP mechanism results in an SQLException with the following error, even when valid information is specified for the LOGDATA parameter (set using URL or DataSource):

SQLState: 28000 Error code: 8017 Message: [Teradata Database]: The UserId, Password or Account is invalid.

Troubleshooting JDBC FastLoad

If an SQLException is encountered during JDBC FastLoad, it may be part of a chain of SQL exceptions. To get the complete picture of the cause for the SQLException, it is necessary to walk through the whole chain of SQL exceptions.

Likewise, if an SQLWarning is encountered during JDBC FastLoad, it may be part of a chain of SQL warnings. To get a complete picture of the cause for the SQLWarning, it is necessary to walk through the whole chain of SQL warnings.

For example:

try {

    PreparedStatement pstmt = con.prepareStatement("INSERT INTO ...");

    try {

        SQLWarning w = con.getWarnings();

        while (w != null) {

            StringWriter sw = new StringWriter();

            w.printStackTrace(new PrintWriter(sw, true));

            System.out.println("SQL State = " + w.getSQLState() +

                               ", Error Code = " + w.getErrorCode() +

                               "\n" + sw.toString());

            w = w.getNextWarning();

        }

        // using JDBC FastLoad

        w = pstmt.getWarnings();

    } finally {

        pstmt.close();

    }

} catch (SQLException e) {

    while (e != null) {

        StringWriter sw = new StringWriter();

        e.printStackTrace(new PrintWriter(sw, true));

        System.out.println("SQL State = " + e.getSQLState() +

                           ", Error Code = " + e.getErrorCode() +

                           "\n" + sw.toString());

        e = e.getNextException();

    }

}

When using JDBC FastLoad, details on data errors may be included in the chain of SQL exceptions mentioned above. Some data error details may be quite lengthy. They are in one of two temporary error tables mentioned in Considerations When Using JDBC FastLoad. For more details on the format of the two temporary error tables, see the section on Error Table Formats in the Teradata FastLoad Reference.

Information on why JDBC FastLoad was not activated can be found in the SQLWarning of a connection, which might be part of a chain of SQL warnings. To get the complete picture of the cause for the SQLWarning, it is necessary to scroll through the whole chain of SQL warnings.

Information on why JDBC FastLoad was not activated also can be obtained by specifying “LOG=INFO” in the URL connection string. Search for “FastLoad ” (note the space after FastLoad) in the resulting LOG output. The same search can be used to find out if JDBC FastLoad was activated.

Here is a sample LOG output that shows JDBC FastLoad was not activated:

Cannot FastLoad because statement is NOT an INSERT!

Here is a sample LOG output that shows JDBC FastLoad was activated:

FastLoad found 2 AMP(s) in anmpc2 and created 2 FastLoadConnection(s) and 2 FastLoadPreparedStatement(s) with SESSIONS=8.

Troubleshooting JDBC FastExport

If an SQLException is encountered during JDBC FastExport, it might be part of a chain of SQL exceptions. To get the complete picture of the cause for the SQLException, it is necessary to walk through the whole chain of SQL exceptions. Likewise, if an SQLWarning is encountered during JDBC FastExport, it might be part of a chain of SQL warnings. To get the complete picture of the cause for the SQLWarning, it is necessary to walk through the whole chain of SQL warnings.

For example:

try {

    PreparedStatement pstmt = con.prepareStatement("SELECT ... FROM     ...");

    try {

        // using JDBC FastExport

        SQLWarning w = pstmt.getWarnings();

        while (w != null) {

            StringWriter sw = new StringWriter();

            w.printStackTrace(new PrintWriter(sw, true));

            System.out.println("SQL State = " + w.getSQLState() +

                               ", Error Code = " + w.getErrorCode() +

                               "\n" + sw.toString());

            w = w.getNextWarning();

        }

    } finally {

      pstmt.close();

    }

} catch (SQLException e) {

    while (e != null) {

        StringWriter sw = new StringWriter();

        e.printStackTrace(new PrintWriter(sw, true));

        System.out.println("SQL State = " + e.getSQLState() +

                           ", Error Code = " + e.getErrorCode() +

                           "\n" + sw.toString());

        e = e.getNextException();

    }

}

Information on why JDBC FastExport was not activated can be found in an SQLWarning of a Connection, which might contain a chain of SQL warnings. To get the complete picture of the cause for the SQLWarning, it is necessary to walk through the whole chain of SQL warnings.

Information on why JDBC FastExport was not activated can also be obtained by specifying “LOG=INFO” in the URL connection string.

Troubleshooting JDBC Monitor

If an SQLException is encountered by the JDBC Monitor, it may be part of a chain of SQL exceptions. To obtain the complete picture of the cause for the SQLException, it is necessary to step through the entire chain of SQL exceptions.

Likewise, if an SQLWarning is encountered by the JDBC Monitor, it may be part of a chain of SQL warnings. To obtain the complete picture of the cause for the SQL Warning, it is necessary to step through the entire chain of SQL warnings.

Here is an example:

try {

    PreparedStatement pstmt = con.prepareStatement("MONITOR VERSION");

    try {

        //bind input values (not shown)

        boolean resultSetAvailable = pstmt.execute();

        //get ResultSet (not shown)

        SQLWarning w = pstmt.getWarnings();

        while (w != null)

            StringWriter sw = new StringWriter();

            w.printStackTrace(new PrintWriter(sw,true));

            System.out.printIn("SQL State = " + w.getSQLState() +

                               ", Error Code = " + w.getErrorCode() +

                               "\n" + sw.toString());

            w = w.getNextWarning();

        }

    } finally {

        pstmt.close();

    }

} catch (SQLException e) {

    while (e != null) {

        StringWriter sw = new StringWriter();

        e.printStackTrace(new PrintWriter(sw, true));

        System.out.printIn("SQL State = " + e.getSQLState() +

                           ", Error Code = " + e.getErrorCode() +

                           "\n" + sw.toString());

        e = e.getNextException();

    }

}

DatabaseMetaData Performance

DatabaseMetaData methods compose queries against the Teradata Database Data Dictionary views. Slow performance of queries against Data Dictionary views can sometimes be due to a lack of accurate, up-to-date statistics.

It is recommended that the Teradata Database administrator execute the following SQL commands on a regular basis to collect statistics on certain Data Dictionary columns and indexes.

collect statistics on DBC.AccessRights column (DatabaseId)

collect statistics on DBC.AccessRights column (FieldId)

collect statistics on DBC.AccessRights column (GrantorId)

collect statistics on DBC.AccessRights column (UserId)

collect statistics on DBC.AccessRights column (UserId, TVMId)

collect statistics on DBC.AccessRights column (TVMId, DatabaseId)

collect statistics on DBC.AccessRights index (UserId, DatabaseId) -- for TD 14.10 and earlier

collect statistics on DBC.AccessRights index (UserId) -- for TD 15.0 and later

collect statistics on DBC.AccessRights index (TVMId) -- for TD 14.10 and earlier

 

collect statistics on DBC.DBase column (DatabaseName)

collect statistics on DBC.DBase column (DatabaseNameI)

collect statistics on DBC.DBase column (JournalId)

collect statistics on DBC.DBase index (DatabaseId)

 

collect statistics on DBC.Indexes column (CreateUID)

collect statistics on DBC.Indexes column (FieldId)

collect statistics on DBC.Indexes column (IndexNumber)

collect statistics on DBC.Indexes column (IndexType)

collect statistics on DBC.Indexes column (LastAlterUID)

collect statistics on DBC.Indexes column (TableId, DatabaseId)

collect statistics on DBC.Indexes column (TableId, FieldId)

collect statistics on DBC.Indexes column (TableId, IndexNumber, DatabaseId)

collect statistics on DBC.Indexes column (UniqueFlag)

collect statistics on DBC.Indexes column (UniqueFlag, CreateUID)

collect statistics on DBC.Indexes column (UniqueFlag, FieldId)

collect statistics on DBC.Indexes column (UniqueFlag, LastAlterUID)

collect statistics on DBC.Indexes index (TableId)

 

collect statistics on DBC.ObjectUsage column (DatabaseId, ObjectId, IndexNumber) -- for TD 14.0 and later

collect statistics on DBC.ObjectUsage column (FieldId) -- for TD 14.0 and later

collect statistics on DBC.ObjectUsage column (IndexNumber) -- for TD 14.0 and later

collect statistics on DBC.ObjectUsage column (ObjectId) -- for TD 14.0 and later

 

collect statistics on DBC.Owners column (OwneeId)

collect statistics on DBC.Owners column (OwnerId, OwneeId)

collect statistics on DBC.Owners index (OwnerId)

 

collect statistics on DBC.RoleGrants index (GranteeId)

collect summary statistics on DBC.RoleGrants -- for TD 14.0 and later

 

collect statistics on DBC.Roles column (RoleId)

collect statistics on DBC.Roles column (RoleNameI)

 

collect statistics on DBC.StatsTbl column (IndexNumber) -- for TD 13.0 and later

collect statistics on DBC.StatsTbl column (StatsType) -- for TD 13.0 and later

 

collect statistics on DBC.TempTables column (BaseTableId)

collect summary statistics on DBC.TempTables -- for TD 14.0 and later

 

collect statistics on DBC.TVFields column (CreateUID)

collect statistics on DBC.TVFields column (DatabaseId)

collect statistics on DBC.TVFields column (FieldId)

collect statistics on DBC.TVFields column (FieldName)

collect statistics on DBC.TVFields column (FieldType)

collect statistics on DBC.TVFields column (LastAlterUID)

collect statistics on DBC.TVFields column (TableId)

collect statistics on DBC.TVFields column (TableId, FieldName)

collect statistics on DBC.TVFields column (UDTName) -- for V2R6.1 and later

 

collect statistics on DBC.TVM column (CommitOpt) -- for TD 12.0 and later

collect statistics on DBC.TVM column (CreateUID)

collect statistics on DBC.TVM column (CreatorName)

collect statistics on DBC.TVM column (DatabaseId)

collect statistics on DBC.TVM column (LastAlterUID)

collect statistics on DBC.TVM column (TableKind)

collect statistics on DBC.TVM column (TVMId)

collect statistics on DBC.TVM column (TVMName)

collect statistics on DBC.TVM column (TVMNameI)

collect statistics on DBC.TVM column (DatabaseId, TVMName)

collect statistics on DBC.TVM index (DatabaseId, TVMNameI)

 

collect statistics on DBC.UDTInfo column (TypeKind) -- for V2R6.1 and later

collect statistics on DBC.UDTInfo column (TypeName) -- for V2R6.1 and later

Slow Logon on Linux

JDBC users might experience a slow logon process when running on a Linux system, varying from several additional seconds to several minutes. This occurs when using the TD2 mechanism, which is the default mechanism for a Teradata JDBC connection. The cause is underlying problems with random number generation, and is documented by the following Java bugs:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6202721

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6366924

Note that the presence of these problems does not guarantee that every logon is slow. Test programs that recreate the problem can run successfully for many iterations before the problem appears. Run the following java program if you suspect this problem.

If there are no problems, the program should finish in a few seconds. If the slow logon problem is present, then it may take several minutes for the program to run. The program prints iteration count for each test run and thus slow progress can be determined by pauses in the program’s output.

//

// This program tests to see if there are delay problems associated the

// use of

// SecureRandom

import java.security.SecureRandom;

import java.util.*;

import java.math.*;

class secRandomPrb {

  public static void main(String args[]) throws Exception {

    System.out.println();

    System.out.println("Pass 1: getInstance:");

    runit(true);

    System.out.println();

    System.out.println("Pass 2: secureRandom:");

    runit(false);

  }

  public static void runit(boolean secRand) {

    SecureRandom srand;

    BigInteger x;

    int ctr = 0;

    try {

      for (ctr = 0; ctr < 1000; ctr++) {

        if (secRand == true)

          srand = SecureRandom.getInstance("SHA1PRNG");

        else

          srand = new SecureRandom();

        byte[] seed = srand.generateSeed(8);

        srand.setSeed(seed);

        x = new BigInteger(512, srand);

        int i = x.intValue();

        System.out.print(ctr + " ");

      }

    }

    catch (Exception ex) {

      System.out.println("Exception: " + ex);

    }

  }

}

If the slow logon problem is present, it can be resolved by specifying “/dev/./urandom”, as a link for /dev/random or as the securerandom.source.

This can be done by Using a Command Line Argument or Changing /dev/random to be a symbolic link.

Using a Command Line Argument

The recommended workaround is to specify a command line argument for starting Java JVM. This allows the change to be made only to java programs that may encounter this problem. The command line setting of:

-Djava.security.egd=file:/dev/./urandom

will fix the problem. Note the extra “.” directory between dev and urandom. This is required. The above test program can be run with this setting as follows:

java -Djava.security.egd=file:/dev/./urandom secRandomPrb

Note that this same property is available in the security file in $JAVA_HOME/jre/lib/security/java.security file. Though normally, a change to the java.security file should provide the same effect, our testing has shown that changes to that file will not resolve the problem when using JDK 5.0.

Changing /dev/random to be a symbolic link

This change requires root permission and will change the setting of /dev/random for ALL programs on your system. You can log in as root and execute the following commands:

mv /dev/random /dev/random.real

ln -s /dev/./urandom /dev/random

After this change is made, the slow logon problem will be fixed. Verify this by running the test program provided above.