take a break - take the leap!

a short clip of my sky dive- hope it encourages others to take the plunge!

DBS CRASHED OR SESSIONS RESET. RECOVERY IN PROGRESS or WSA E HOST UNREACH

This seems to be a fairly common stumbling block for Teradata users. I understand that most (if not all) applications connecting to Teradata interface using TPA or Trusted Parallel Application. I do not know if there any desktop applications which don't, so here goes a summary of the problem and a probable solution.

You are able to ping the Teradata node. When you try to login using BTEQ or SQL Assistant, you get an error message. For BTEQ the error message is this:

Warning: DBS CRASHED OR SESSIONS RESET. RECOVERY IN PROGRESS

For SQL Assistant, its WSA E HOST UNREACH (see the earlier blog for screenshot)

The simple solution might be start the TPA daemon on the server.

/etc/init.d/tpa start

Here's the full text:

(none):~ # /etc/init.d/tpa stop
PDE stopped for TPA shutdown
(none):~ # netstat -an | grep 1025
(none):~ # bteq

 Teradata BTEQ 12.00.00.00 for LINUX.
 Copyright 1984-2007, NCR Corporation. ALL RIGHTS RESERVED.
 Enter your logon or BTEQ command:
.logon suse/partha

.logon suse/partha
Password:

 *** Warning: DBS CRASHED OR SESSIONS RESET.  RECOVERY IN PROGRESS>
 *** Warning: Exiting because of three BREAKs!

 *** Exiting BTEQ...
 *** RC (return code) = 2
(none):~ # netstat -an | grep 1025
(none):~ # /etc/init.d/tpa start
Teradata Database Initiator service is starting...
Teradata Database Initiator service started successfully.
(none):~ # netstat -an | grep 1025
(none):~ # bteq

 Teradata BTEQ 12.00.00.00 for LINUX.
 Copyright 1984-2007, NCR Corporation. ALL RIGHTS RESERVED.
 Enter your logon or BTEQ command:
.logon suse/partha

.logon suse/partha
Password:


 *** Logon successfully completed.
 *** Teradata Database Release is 12.00.03.12
 *** Teradata Database Version is 12.00.03.14
 *** Transaction Semantics are BTET.
 *** Character Set Name is 'ASCII'.

 *** Total elapsed time was 9 seconds.

 BTEQ -- Enter your DBC/SQL request or BTEQ command:
select current_date;

select current_date;

 *** Query completed. One row found. One column returned.
 *** Total elapsed time was 2 seconds.

    Date
--------
11/09/07

 BTEQ -- Enter your DBC/SQL request or BTEQ command:
.quit

.quit
 *** You are now logged off from the DBC.
 *** Exiting BTEQ...
 *** RC (return code) = 0
(none):~ # netstat -an | grep 1025
tcp        0      0 0.0.0.0:1025            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:42528         127.0.0.1:1025          TIME_WAIT
tcp        0      0 127.0.0.1:42527         127.0.0.1:1025          TIME_WAIT
(none):~ # netstat -an | grep 1025
tcp        0      0 0.0.0.0:1025            0.0.0.0:*               LISTEN
(none):~ #

and here's the screenshot:

don't get caught due to a missing cop1

Most Teradata clients expect to find the Teradata servername in a specialized form in the hosts file. This is /etc/hosts in Linux and <OSDRIVE>\Windows\System32\drivers\etc\hosts in Windows. Turns out that some tools like Teradata SQL Assistant can't locate the server even if you put the full IP address in the ODBC connection. 

 

The client shows an error like this:

0: WSA E HostUnreach: The Teradata server can't currently be reached over this network.

The simplest solution is to add an entry in the hosts file (typical location given above) with the Teradata node name followed by cop1 (or cop2 etc). Here's how it should look now:

# comment
# lines

# here

192.168.93.128   suse susecop1

Note that I have added two entries. While suse is actually the name of the remote server, I have appended a cop1 in the next one for Teradata tools to figure out this is a Teradata server!

Thanks to Jim Chapman for explaining this in this post.

If you are not able to logon using BTEQ or Teradata SQL Assistant, there might be a problem with the Trusted Parallel Application (TPA) daemon. More on that in the next entry.