Grid control and non-default listener

Question

I have oem 10.2.0.5 on linux redhat 5
i have a series of databases with 2 oracle homes on solaris.
1. we use virtual IPs instead of the host ip. so one IP for each database. This is due to our active/passive cluster. I have read the documentation on this. I was able to configure for this by taking the tnsnames file and using that in the target configration.
My problem now is that the OEM sees my listener as being down. I think this is because it is looking for the default listener on port 1521. We have 1 listener per database and they are on non-default ports. This is for our active/passive failover.
how do I configure the target to look for the correct listener? so I do not have a listener called listner.
My listener has the same name as the database name and is on the same port as my database.

Answer 1

Guess2 wrote:
I have oem 10.2.0.5 on linux redhat 5
i have a series of databases with 2 oracle homes on solaris.
1. we use virtual IPs instead of the host ip. so one IP for each database. This is due to our active/passive cluster. I have read the documentation on this. I was able to configure for this by taking the tnsnames file and using that in the target configration.
My problem now is that the OEM sees my listener as being down. I think this is because it is looking for the default listener on port 1521. We have 1 listener per database and they are on non-default ports. This is for our active/passive failover.
how do I configure the target to look for the correct listener? so I do not have a listener called listner.
My listener has the same name as the database name and is on the same port as my database.Your database isn't "on" a port, so the fact that you make a statement like "My listener . . . is on the same port as my database." indicates you don't yet have a clear understanding of the relationship of the listener to the database. The fact that you would name your listener the same as your database further indicates you don't yet have a clear understanding of the relationship of the listener to the database.
The database (actually, we're talking about the instance) really has no inherent relationship to the listener. The listener is just a connection broker. One listener, listening on one port, can service requests for multiple databases, even multiple versions (9.x, 10.x) databases, even databases running out of different homes. For that reason alone, I consider it bad practice to name a listener the same as a database. That implies a relationship that simply doesn't exist. Only under extraordinary circumstances would it be necessary to have more than one listener running on a server, regardless of how many database instances may be on that server. And for that reason it really doesn't make much sense to name your listener anything but the default - "listener".
You configure your listener to listen on a certain ip and port. You configure your clients (via tnsnames or other naming method) to send connection requests to the ip and port the listener was configured to listen for, requesting a connection to a service name the listener knows about. The listener knows about service names either through coding in the SID_LIST section of listener.ora, or through self-registration by the instance.
I worked with active/passive clusters with virtual IP's a few years ago and there was really nothing special I had to do as far as the databases, clients, or listeners.