A long notes (confusing) on listeners in 11gR2 RAC.
You all aware of we have two listeners running in database servers in Grid Infrastructure (Aka RAC) namely scan listeners and node listeners.
How does they work?
The SCAN works by being able to resolve to multiple IP addresses reflecting multiple listeners in the cluster handling public client connections. When a client submits a request, the SCAN listener listening on a SCAN IP address and the SCAN port is contracted on a client’s behalf. Because all services on the cluster are registered with the SCAN listener, the SCAN listener replies with the address of the local listener on the least-loaded node where the service is currently being offered. Finally, the client establishes connection to the service through the listener on the node where service is offered. All of these actions take place transparently to the client without any explicit configuration required in the client.
Note that: Client only knows the scan name. DNS redirects the connection request to one of the scan listeners in the cluster.Then the client and local listener communicate between each other and the connection becomes established.Scan listeners register the database services via IPC/TCP through pmon and Local listeners registers both the database and ASM instances via IPC/TCP through pmon.
A picture can save 100 words of explanation
We have 3 scan listeners , registering the IPC(TCP) end points as the RAC instances (remote_listener) registered with PMON of rac instances and the PMON also registers to node listeners (local_listener) which actually points to your database.
- Indeed they both run from the same home (Grid Home), but for different functionality. From 11gR2 onwards these listeners are part of clusterware and managed by oraagent. This oraagent take care of listeners. This oraagent spawned by crsd takes care of our listeners in terms of configuration and monitoring.
- Especially when the listener is started by oraagent you can see the lines in the listener.ora file #line added by agent.
- Another important aspect of the listener.ora files are these files are managed by oraagent, whenever there is a clusterware command is used to manage this listeners. for example srvctl etc.
- Further, the listeners will be monitored by oraagent process every 60 seconds, which you can find in the $GRID_HOME/log/nodename}/agent/crsd/oraagent_oracle/oraagent_oracle.log
- You must set the local_listener and remote_listener parameter to scan listener, description or address list of the same. Since these is the only way now to register your database/instance to scan listener. Even if you dont specify the oraagent will automatically add local_listener values , but you must exclusively set remote_listener parameter to cluster scan name which will provide you the TAF.
If you delete the listener.ora and restart the listener with srvctl start listener, a listener.ora will reappear. The original configuration will reappear in listener.ora and the manually modified listener.ora will be renamed (with a timestamp suffix)
- The agent also creates and maintains the file: endpoints_listener.ora this file is there for backward compatibility,
- Oraagent comes into action also at instance startup, when the instance is started with srvctl (as opposed to ‘manually’ started instance from sqlplus) and sets LOCAL_LISTENER parameter, dynamically (this is done with an alter system command and only if the parameter has not been set on spfile).
You may also has observed in listener.ora file there were no tcp/ip settings, Where are the TCP/IP settings of my listeners in listener.ora? and Only IPC endpoints are listed in listener.ora, As you see below the listener.ora contains only scan listener which contain IPC protocol.
when we add a listener using srvctl; listener defition is added to the cluster repository . When we use srvctl to start
the listener, oraagent looks to the repository to see the listener defition for that listener, if there is a correct
listener definition in repository-> it updates the listener.ora and starts the listener.
if there isnt any listener definition in repository -> it just cannot start the listener.
if there is a correct listener definition in repository and(&&) if there is a false listener definition -> it cannot
start the listener but this time produces tns error or listener specific error, but at least it tries.
FOR PROPER INFORMATION PLZ VISIT: