ping, tnsping

The three main things to check for diagnosing remote database connection problems are the machine, the listener, and the database. The utilities that can be used to test each one of these include ping , tnsping , and a database connection, as depicted below:

The ping utility is used to test the connectivity to a remote machine. ping will indicate whether a remote server is accessible and responding. If the ping command indicates that a machine cannot be accessed, the other connectivity tests will also fail.

The ping utility is usually found in /usr/sbin on UNIX machines and simply reports the health of the remote machine specified:

$ ping asgard

asgard is alive

Used with the –s option, ping will show the packets received and timing information.

oracle@asgard:/usr/sbin > ping -s grace

PING gracelan: 56 data bytes

64 bytes from grace.bmc.com (172.18.16.215): icmp_seq=0. time=0. ms

64 bytes from grace.bmc.com (172.18.16.215): icmp_seq=1. time=0. ms

64 bytes from grace.bmc.com (172.18.16.215): icmp_seq=2. time=2. ms

64 bytes from grace.bmc.com (172.18.16.215): icmp_seq=3. time=0. ms

64 bytes from grace.bmc.com (172.18.16.215): icmp_seq=4. time=0. ms

64 bytes from grace.bmc.com (172.18.16.215): icmp_seq=5. time=0. ms

----gracelan PING Statistics----

6 packets transmitted, 6 packets received, 0% packet loss

round-trip (ms) min/avg/max = 0/0/2

The ping command can also be executed at the DOS prompt on Windows machines to test client-to-server connectivity:

D:\> ping asgard

Pinging asgard.bmc.com [198.64.245.67] with 32 bytes of data:

Reply from 198.64.245.67: bytes=32 time<10ms TTL=254

Once connectivity to the host is confirmed with ping, the next connection to test is the listener. The tnsping utility is used to determine whether or not an Oracle service can be successfully reached. If a connection can be established from a client to a server (or server to server), tnsping will report the number of milliseconds it took to reach the remote service. If unsuccessful, a network error will be displayed. However, tnsping will only report if the listener process is up and provides no indication of the state of the database.

$ tnsping <net service name> <count>

The “net service name” must exist in the tnsnames.ora file. This file is used by clients and database servers to identify server destinations. It stores the service names and database addresses. The “count” parameter is optional and will show the number of times the command should try to connect to the specified service name.

$ tnsping GRACELANV8_GRA901m 5

TNS Ping Utility for Solaris: Version 9.2.0.1.0 - Production on 03-JAN-2003 14:47:09

Used parameter files:

/usr/oracle/9.2.0/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=gracelan)

(PORT=1525)) (CONNECT_DATA= (SID=GRA901m)))

OK (80 msec)

OK (10 msec)

OK (0 msec)

OK (10 msec)

The result from the tnsping command above shows 80 milliseconds (ms) were required for the first “ping”. During this time period, the alias GRACELANV8_GRA901m from the local tnsnames.ora file was retrieved, a DNS of the host “gracelan” was resolved, and the TNS connect and refuse packets were transported. The second trip took only 10 ms because all of the connection information was already cached.

tnsping can be used to test listener connectivity but not database performance. While ping usually returns faster than tnsping, it gives no indication whether or not SQL*Net is performing. The ping utility simply uses IP to try to reach a destination, whereas tnsping uses TCP (a socket) and transfers data between two nodes. As a result, the ping utility will always be faster. A slow tnsping round trip could indicate any number of problems, including a very active server or a slow network.

To reach an Oracle Names Server with tnsping, the command can be formatted as shown below:

$ tnsping ‘(ADDRESS=(PROTOCOL=tcp)(HOST=onames-server)(PORT=1575))’

Once the host and listener connectivity have been verified, the final connectivity test is the database itself. The host could be accessible and the listener active, yet the database might still be inaccessible. Granted, this final test could be performed first and the others (ping, tnsping) performed only if this test fails, since if the database is accessible, so are the database host and listener. Any type of database connection can be used to confirm database connectivity (SQL*Plus, JDBC, ODBC, Pro*C).

The Java program (ConnectionTest.java) will parse a tnsnames.ora file and display the connectivity status of every entry in the file. It does this by establishing a JDBC connection with each entry in the file. The tnsnames.ora file must be in the same directory as the Java program in order to be found and parsed. In addition, the program requires that the same username and password be used for all connections.

< ConnectionTest.java (not listed – See online code depot)

The Java program can be used to regularly monitor the availability of all databases in the tnsnames.ora file. It requires that the JDBC driver be listed in the CLASSPATH.

The tnsnames.ora entries are typically in the following format and are easily parsed by ConnectionTest.java:

ASGARDV8_ASG817t= (DESCRIPTION=

(ADDRESS=

(PROTOCOL=TCP)

(HOST=asgard)

(PORT=1525)

)

(CONNECT_DATA=

(SID=ASG817t)

)

When the program is executed, it will display the status of each connection listed in the file:

$java ConnectionTest system manager

FENRISV8_FEN920wa Successful

MINOTAURV8_MIN817wa Unsuccessful

MINOTAURV8_MIN8173x Successful

NT817LEE Successful

ANGUSV8_ANG817us Successful

JARAIXV8_AIX817r Successful

ASGARDV8_ASG806r Successful

Each entry in the file takes between 3 and 5 seconds to process. This may or may not be feasible in environments with many entries to test.