A more precise introduction of SCAN listener in RAC 11g


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.

For example,

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.

In a 11gR2 Rac environment, srvctl should be used to manage the listeners.. Adding, removing, starting and stopping the listeners should be made by using srvctl commands. By using srvctl management is easier.. Oraagent takes the control, checkes our resources with this.
Using $GRID_HOME for listener home is recommended, by using $GRID_HOME for all our listeners, we have a centralized location and environment for all of our listener processes. This also simplifies the management activities..
On the other hand, if you want to use manual technics for listener declaration and management in a RAC envrionment, it is possible ,as well.





Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s