Thursday, August 27, 2009

ping,tnsping

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 rwcash
PING rwcash.imany.com (10.50.0.68) 56(84) bytes of data.


64 bytes from 10.50.0.68: icmp_seq=0 ttl=64 time=0.146 ms


64 bytes from 10.50.0.68: icmp_seq=1 ttl=64 time=0.132 ms

--- rwcash.imany.com ping statistics ---


2 packets transmitted, 2 received, 0% packet loss, time 2000msrtt min/avg/max/mdev = 0.107/0.109/0.112/0.002 ms, pipe 2


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

D:\> ping rwcash
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 "netservice 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 rwcash_eng10g01 3


TNS Ping Utility for Linux: Version 10.2.0.3.0 - Production on 27-AUG-2009 04:34:56


Copyright (c) 1997, 2006, Oracle. All rights reserved.


Used parameter files:


Used TNSNAMES adapter to resolve the alias


Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST =rwcash.imany.com)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = ENG10G01)))


OK (60 msec)


OK (10 msec)


OK (10 msec)



The result from the tnsping command above shows 60 milliseconds (ms) were required for the first “ping”. During this time period, the alias rwcash_eng10g01 from the local tnsnames.ora file was retrieved, a DNS of the host “rwcash” 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.

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).

No comments:

Post a Comment