Stumper: Oracle Listener returns short Hostname

[Adam Garsha]

We are migrating from Tru64 to HP-UX. We are having problems with our Oracle Listeners returning the unqualified short hostnames to clients when they ask the listener(s) about the whereabouts of a running Oracle instance among the nodes in the cluster.

I've tried:
1. setting the HOSTNAME=FQDN in /etc/netconf
2. reversing the order (short first, FQDN-version second) of node host entries in /etc/hosts
3. putting dns before files in /etc/nsswitch and adjusting timing and retries in /etc/resolv.conf
4. and combinations of above...

Nothing seems to work. The problem is that our clients are on a different network domain then our UNIX systems... when they get back a short name, like "its-db1"... they can't resolve it (because we don't have the UNIX domain in the search suffix list).

There are work-arounds (e.g. suffix search list and duplicate DNS entries), but they all seem cludgier then having the listener correctly return the FQDN to clients.

Has no one run into this difficulty before?

HP-UX 11.23 on Itanium hardware. Oracle 10g2.

Any further ideas? My current thought is that maybe oracle is using "uname -n" under the hood when the databases register with the listeners (i.e. tell the listeners which node they are on).

We have a case open with Oracle, but it is going no-where.

We can't be the only folks running their UNIX systems in a different domain then our windows workstations. Any tips/insight appreciated.

Also, an aside, what is the "correct" way to define HOSTNAME in netconf? short or FQDN?

Thanks.

[Adam Garsha]

Oh, yes. On our Trucluster systems, `hostname` and `uname -n` both return the FQDN and we didn't have this problem. Seems (perhaps correctly ) that HP-UX limits `uname -n` entries to the short name and/or less then 8 chars.

[Hein van den Heuvel]

>> when they get back a short name, like "its-db1"... they can't resolve it (because we don't have the UNIX domain in the search suffix list).


This has me puzzled.
How did they get over there in the first place? They must have known!? So keep on using that?

Were they using 'local naming' with a fully qualified name not in their local tnsnames file?
Are the clients using 'directory naming' with soem ldap compliant directory server?
Using the (retired?) Oracle Names Server?

Perhpas the entries inteh listener.log can give a good clue as to wht it being used?

Is the DB_DOMAIN init.ora parameter set up correctly at the server side?

hope this helps some,
regards,

Hein van den Heuvel

[Adam Garsha]

The local names file has the fully qualified path to the hosts. It is only a problem when their initial connection isn't to the correct server and the listener tells them to go to node X instead. All oracle instance cross register to every listener (only 3 listeners, 1 per node).

[Adam Garsha]

All Oracle connection attempts are sent to its-db.XXX.YYY which is a virtual IP (in an SG package). We want to have a
"global" listener that accepts all connnections for Oracle and redirects them to the proper node. All instances cross
register with the listener on each node of the cluster. The virtual IP is what the clients target. Since there is a listener
on each node in the cluster, and since all oracle instances cross register, they should always get information about where
they need to reconnect. That is the problem... the information fed back only includes the short hostname.

I. Sniffer trace of client connecting to its-db, trying to reach "SYSTEST" SID:

Client connects to wrong cluster node (its-db virtual IP is aliased on an its-db1 interface):


.........9.,...............:....AA........................(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=its-db1.XXX.YYY)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=SYSTEST)(CID=(PROGRAM=)(HOST=wrench)(USER=oracle)))).

Database Response to connection to server that is not hosting the database (note that 'its-db3' is returned:

.................@(ADDRESS=(PROTOCOL=TCP)(HOST=its-db3)(PORT=1521)).(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=its-db1.XXX.YYY)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=SYSTEST)(CID=(PROGRAM=)(HOST=wrench)(USER=oracle))(SERVER=dedicated)(INSTANCE_NAME=SYSTEST)))

II. Here is what tnsnames.ora looks like:

LISTENER =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = its-db1.XXX.YYY)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = its-db2.XXX.YYY)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = its-db3.XXX.YYY)(PORT = 1521))
)
)

....

SYSTEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = its-db.XXX.YYY)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = SYSTEST)
)
)

....


III. Here is what "lsnrctl services" shows:

LSNRCTL for HPUX: Version 10.2.0.2.0 - Production on 22-JAN-2007 08:25:32

Copyright (c) 1991, 2005, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
Services Summary...
...
Service "SYSTEST" has 1 instance(s).
Instance "SYSTEST", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:1 refused:0 state:ready
REMOTE SERVER
(ADDRESS=(PROTOCOL=TCP)(HOST=its-db3)(PORT=1521))
Service "SYSTESTXDB" has 1 instance(s).
Instance "SYSTEST", status READY, has 1 handler(s) for this service...
Handler(s):
"D000" established:0 refused:0 current:0 max:2046 state:ready
DISPATCHER < its-db3="">
(ADDRESS=(PROTOCOL=tcp)(HOST=its-db3.XXX.YYY)(PORT=63722))
Service "SYSTEST_XPT" has 1 instance(s).
Instance "SYSTEST", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:1 refused:0 state:ready
REMOTE SERVER
(ADDRESS=(PROTOCOL=TCP)(HOST=its-db3)(PORT=1521))
...
The command completed successfully

[Adam Garsha]

So to be clear. In the text above, SYSTEST is running on its-db3.XXX.YYY, the client connects to a listener at its-db.XXX.YYY and the listener tells it to connect to "its-db3".

The client is not in the XXX.YYY domain and does not have XXX.YYY in its DNS search suffix list and so it fails to connect.

[Hein van den Heuvel · Accepted solution]

Could this be a listener.ora setting issue?

Perhaps you can clone a section in there to play with and then change the various occurances of 'its-db3' to 'its-db3-a', 'its-db3-b' and so on.
Now in the listener.log or network sniffer see which piece of string is being picked up?

Below a possibly interesting quote from
"Oracle Clusterware and Oracle Real Application Clusters
Administration and Deployment Guide".
I just happened to spot that, but it may well be the wrong context (VIP):

http://www.oracle.com/pls/db102/to_pdf?pathname=rac.102%2Fb14197.pdf&remark=portal+%28Administration%29

"Your Listener.ora file should contain one entry for the virtual
internet protocol (VIP) address, using the VIP's name, and another
entry for the physical host, by IP address not name.
:
Making Applications Highly Available Using Oracle Clusterware 14-5"

hth,
Hein.