Re: tnsping times intermittently high

<sybrandb_at_hccnet.nl> wrote in message
news:3u9j93hn87a3j7phhees68jlcbfh2190fd_at_4ax.com...
> On Sun, 15 Jul 2007 02:01:11 GMT, "Gerald Sinkiewicz"
> <sinkiege_at_snet.net> wrote:
>
>>A bit strange:
>>
>>1. tnsnames.ora uses host = ipaddress, not FQDNS names.
>>2. tnsping from the box (AIX5L) to one alias on the same box comes back at
>>times OK (10msec) at other times
>>OK (19000msec) or more.
>>It was high for a period of a couple of hours, then the problem went away,
>>well was still on-and-off
>>at high numbers, but mostly OK (0msec).
>>3. tnsping to other tns aliases on the same box did not show degraded
>>performance at anytime.
>>4. there are about 15 distinct listeners on the box (actually it is an HA
>>cluster of 2 boxes but not RAC) each has its own IP address and distinct
>>port number.
>>5. Only one of the listeners is showing this degradation, all the others
>>are
>>consistenly 10msec.
>>6. Eventhough there are no DNS names in the tnsnames.ora file, the problem
>>seems to have come from
>>a reverse dns lookup than oracle TNS was doing. We found the primary DNS
>>was
>>having a slow time doing
>>a reverse lookup of just this one IP Address (this time). The secondary
>>DNS
>>was not slow for the same
>>reverse lookup. We fixed the problem with the slow connections and tnsping
>>high by swapping primary and secondary
>>DNS's.
>>7. A similar issue has occured with the same primary DNS a few weeks back
>>but no Oracle related. The victum then
>>was a couple of mail hubs.
>>
>>So, why does tns do a reverse IP address lookup at all, it seems from our
>>experience that it does?
>>Maybe it is for its listener.log or something like that?
>>Or am I thinking incorrectly (again)?
>>
>
> 1 Your post doesn't have a version number, so no one will be capable
> to answer it correctly
> 2 I can't think of any reason to do tnsping on a structural basis.
> I'm not sure why you believe you constantly need to execute tnsping
> 3 I also can't think of any reason to have 15 listeners on a server.
> 4 Oracle has always recommended against using hardcoded IP addresses
> 5 As far as I know tnsping doesn't do a reverse lookup, but why don't
> you enable tnsping tracing (tnsping.trace_level = 16 in sqlnet.ora)
> before posting a bunch of wild guesses.
>
> I would recommend discontinue to use tnsping on a structural basis,
> this will also result in the 'problem' going away automatically.
>
> --
> Sybrand Bakker
> Senior Oracle DBA

I forgot to mention that we were having a client connection problem.

Version of oracle is 9.2.0.8.

Not doing tnsping for fun, there was a slow client connection, slow as in forever.
We don't execute tnsping constantly unless trouble shooting a networking issue, like the one we were having.

The cluster is a Veritas high availability cluster (failover cluster) with two active nodes and 15 failover groups. Each group needs to have its own listener based on a virtual IP. The listeners travel with the instances if a failover occurs (for maintenance, etc.). Although it is possible to listen on one server for an instance on another, I tend to try to avoid that configuration.

Oracles recommendation on hardcoded IP's is well taken, there are advantages to using DNS for sure, but at the
moment the VIP's in the cluster have "temporary" DNS names which if used would mean a change somewhere
down the road and an outage. The outage is very difficult to get in this case from a business perspective. Why
they could not give out permanent DNS names, I don't know, it is another group not under our control.

Thanks for the suggestion on tnsping.trace_level = 16 in sqlnet.ora, that is something I can do on an unimportant
client box.

The guess is not too wild. That the primary DNS server was having difficulty with this IP was seen via nslookup
we also saw via nslookup that the secondary DNS was not having a problem with the same IP. The network slowness
for the client connection and tnsping went away as soon was we switched primary and secondary DNS.
To me it seems reasonable that TNS might issue a gethostbyaddr so that it can fill in the listener.log entry and perhaps some other internal information related to a connection. It must do a gethostbyname or something like that when translating DNS names.

I plan to submit an SR to Oracle on Monday, but at this point the production outage is fixed. Received on Sun Jul 15 2007 - 15:04:17 CDT