Oracle listener running on a private IP address

[Former Member]

Hi everybody

I'm a bit stumped.

We have a private 147.x high speed network on which we have a DB/CI and 2 app servers, and they are also on a 10.x ‘public’ network (which is pingable/reachable from desktops).

When we moved the DB/CI from an old server to a new partition (literally taking the network card out of the back and using an Ignite backup to completely replicate the system, even with the same hostname), the app servers wouldn’t start. There was a TNS error message. We noticed that doing a "lsnrctl status" on the database server it showed an IP address on the 10.x network. When we did a ‘ping’ from either of the app servers they were looking for the DB/CI on the 147.x private network.

So we assumed something had been missed in the ignite rebuild and changed the listener.ora and /etc/hosts files and restarted the listener – could now see it running with that IP and hey presto Bob’s your Uncle put the kettle on it’s all working and the app servers started.

EXCEPT… it wasn’t supposed to run on the 147.x address because now none of the DBA guys monitoring scripts can see the listener – 147.x isn’t reachable from anywhere else.

So the problem must have been with the routing elsewhere…

Next weekend I will change the listener back. To get the app servers working again I can amend their host entries to point to the 10.x address instead. BUT… what then is the point of the dedicated high speed links? Will they even be used?

We shouldn’t have to change anything on the app servers as we hadn’t touched them… and we know the listener on the database server should be running on the 10.x address… but it has changed servers and there may be some internal routing config missing… should it somehow receive the incoming requests on the 147.x address and be able to resolve these to the listener running on the 10.x address?

Any ideas???

This is 4.6c on Oracle 9.2 on HP-UX 11.11.

[Former Member]

Thanks for the answer, didn't get to try this however. What we did was added another line to the listener with a secondary name (in the hosts file) pointing to the public IP address, and on a different port number.

That way the app servers could connect on the internal IP address and the others (such as standby server) could connect to the listener (after after to tnsnames) on the new port number / public IP address.

[Former Member]

Dear Ross,

Acc my unstdng from ur posting.

After changing the IP address in Listener configuration file LISTENER.ORA

and TNSNAMES.ORA, clients attempting to connct to the database receive the

following error:ORA-12535, 00000, "TNS:operation timed out".

The IP address/es for the server were changed.The IP addresses in Listener configuration file LISTENER.ORA and TNSNAMES.ORA were changed accordingly.

To Fix this Engage your System/Network Administrator to flush the DNS cache.

after changing the IP address of the server, you need to remember to

change the IP address in the "/etc/hosts" file.You need to delete the "listener.ckp" file.And reload listener.

If a system with multiple IP addresses the Listener has been configured with a hostname or address which points to an IP different than the one to which the system hostname points; because of this the listener will bind only to that particular IP.Finally Please check whether you have any hardcoded IP addresses present in the following places: Listener configuration (LISTENER.ORA on server)

TNS Name Services (TNSNAMES.ORA on server and clients).it would be best that before (re)starting the server / client services to check whether the DNS hostnames properly resolve to their expected new IP addresses.

Regards

Vinod