How to use SCAN and node listeners with different ports?

How to use SCAN and node listeners with different ports? (文档 ID 1585786.1)转到底部

---

修改时间:2014-2-17类型:BULLETIN

In this Document

 Purpose Scope Details References

---

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.1 to 11.2.0.4 [Release 11.2]
Information in this document applies to any platform.

PURPOSE

This note describes how to use SCAN and listeners with different port numbers for various purposes. There is no general requirement to do this using an Oracle RAC 11g Release 2, as the overall idea is that any client will use the SCAN as its initial entry point and will then be connected to the respective instance and service on the node this service is most suitably served on using the node listener on this node. However, there may be reasons to support applications to maintain a distinguishable connect string on host / port level, which can be established in multiple ways, of which some are described in the following.

SCOPE

For the purpose of allowing applications to maintain a distinguishable connect string on host / port level using one SCAN as the host or to enable port-based firewall configurations, SCAN can be set up to support more than one port. It needs to be noticed that different ports are only used for an initial connect. Once a connection using SCAN on any SCAN port has been established, port assignment is not maintained and routing of connections within the Oracle RAC cluster is performed using database services registered with one or more local listeners. This means that all SCAN ports are treated the same, so that a connection that comes in on any SCAN port can be directed to any registered local listener on any port.

DETAILS

DBCA Default Configuration

Any Oracle 11g Rel. 2 database that is created using the DBCA will use a default configuration, which in short can be described as follows:

A simple configuration is used, regarding the ports and numbers of listeners in the cluster. Basically, the assumption is that 1 SCAN listener, running on 1-3 nodes in the cluster, will work with 1 node listener, running on all of the nodes in the cluster. In addition, most examples assume that both listeners actually use the same port (default 1521). At times, it seems desirable to use dedicated listeners per database either on the same or a different port. There is no general requirement to do this using an Oracle RAC 11g Release 2, as the overall idea is that any client will use the SCAN as its initial entry point and will then be connected to the respective instance and service on the node this service is most suitably served on using the node listener on this node.

This assumes that the respective database that the instance belongs to and that the service is assigned to uses the correct entries for the LOCAL_LISTENER and REMOTE_LISTENER instance parameters. The defaults for the case described would be: LOCAL_LISTENER points to the node listener on the respective node and the REMOTE_LISTENER points to the SCAN. Example: 



remote_listener: cluster1:1521
local_listener: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=1521))))




Some listener and listener architecture used in in Oracle RAC 11g Release 2 fundamentals

• With Oracle RAC 11g Release 2 using SCAN is the default.
• SCAN is a combination of an Oracle managed VIP and a listener.
• The SCAN listener represents a standard Oracle listener used in a certain way.
• As with other listeners, there is no direct communication between the node and the SCAN listeners.
• The listeners are only aware of the instances and services served, since the instances (PMON) register themselves and the services they host with the listeners.
• The instances use the LOCAL and REMOTE Listener parameters to know which listeners to register with.
• Any node listener is recommended to be run out of the Oracle Grid Infrastructure home, although the home that a listener uses can be specified.
• Listeners used for a client connection to Oracle RAC should be managed by Oracle Clusterware and should be listening on an Oracle managed VIP.

Given these fundamentals, there does not seem to be a compelling use case, why multiple listeners or dedicated listeners per database should be used with 11g Rel. 2 RAC, even if they where used in previous versions. The most reasonable use case seems to be manageability in a way that some customers prefer to stop a listener to prevent new client connections to an assigned database as opposed to stopping the respective services on the database, which mainly has the same effect (note that the standard database service - the one that is named after the database name - must not be used to connect clients to an Oracle RAC database anyways, although being used in this example for simplicity reasons.)

If the motivation to have this setup is to assign certain listeners as an entry point to certain clients, note that this would defeat the purpose of SCAN. However, SCAN can be set up to support more than one port. It needs to be noticed that different ports are only used for an initial connect. Once a connection using SCAN on any SCAN port has been established, port assignment is not maintained and routing of connections within the Oracle RAC cluster is performed using database services registered with one or more local listeners. This means that all SCAN ports are treated the same, so that a connection that comes in on any SCAN port can be directed to any registered local listener on any port. 

Using multiple ports with SCAN is subject to version restrictions as follows: 11.2.0.3 does not allow for setting up multiple ports on one SCAN. With 11.2.0.2 this setup would have been possible. Starting with 11.2.0.3.6 (and higher) setting up multiple ports for one SCAN is possible again and supported for the purpose stated above. This issue is tracked in unpublished BUG 13798847.

 A typical client TNSNAMES entry for the client to connect to any database in the cluster would by default look like the following:
  

testscan1521 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = cluster1)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL)
    )
  )

  
In this TNSNAMES entry "cluster1" is the SCAN name, typically registered in the DNS as mentioned. This entry will connect any client using "testscan1521" to any database in the cluster assuming that node listeners are available and the database is configured accordingly using the following configuration:

remote_listener: cluster1:1521
local_listener: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=1521))))


If the motivation to have dedicated listeners for the database is so that clients would get different connection strings to connect to the database (e.g. different host entries or ports) SCAN cannot be used and the node listeners need to be addressed directly, as it used to be the case with previous versions of Oracle RAC. In this case, the SCAN is basically not used for client connections. Oracle does not recommend this configuration, but this entry will explain its configuration later on.



Changing the port of the SCAN listeners only
Note 1: in the following only 1 SCAN listener is used for simplification reasons.

• Get the name of the scan listener: srvctl status scan_listener returns: LISTENER_SCAN1
• Get the port of the scan listener: lsnrctl status LISTENER_SCAN1 returns: 1521
• Change the port of the SCAN listener: srvctl modify scan_listener -p 1541 new port 1541
• Restart the SCAN listener: srvctl stop scan_listener followed by srvctl start scan_listener
• Double-check using lsnrctl status LISTENER_SCAN1 - this should show port 1541
  
  Note 2: Your SCAN listener does not serve any database instance at this point in time, as the database has not been informed about the change in port for the SCAN or their remote listener. In order to have the database instances register with the SCAN listener using the new port, you must alter the REMOTE_LISTENER entry accordingly:
• alter system set remote_listener='cluster1:1541' scope=BOTH SID='*';
• alter system register;
• Double-check using lsnrctl status LISTENER_SCAN1 that the instances have registered.
  
  With this change the following configuration has been established:
• The SCAN listener port has been changed to port 1541 (was: 1521)
• The node listeners - here named LISTENER - still use port 1521
• In order for clients to be able to connect, change their TNSNAMES.ora accordingly:  



testscan1541 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = cluster1)(PORT = 1541))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL)
    )
  )

 

Adding additional node listeners to the system using different ports
So far, only one node listener (listener name LISTENER) on the respective node VIP (here: 192.168.0.61) on port 1521 has been used. The idea of having dedicated listeners per database would mean that additional node listeners need to be created, using the same IP, but preferably different ports. In order to achieve this configuration, perform the following steps (the Grid Infrastructure software owner should have enough privileges to perform these steps, hence the user is not explicitly mentioned):

• Add an additional node listener using port 2011 for example: srvctl add listener -l LISTENER2011 -p 2011
• Start the new node listener: srvctl start listener -l LISTENER2011
• Double-check using: srvctl status listener -l LISTENER2011
• Double-check using: lsnrctl status LISTENER2011 

Note 1: The srvctl command "add listener" does allow specifying an Oracle Home that the newly added listener will be running from and yet have this listener be managed by Oracle Clusterware. This entry does not elaborate on these advanced configurations. 

Note 2: Your new node listener does not serve any database instance at this point in time, as the database has not been informed that it should connect to the newly created listener. In order to have the database instances register with this listener, you must alter the LOCAL_LISTENER entry for each instance accordingly:

• alter system set local_listener='(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=2011))))' scope=BOTH SID='OCRL1';
• alter system register;
• Double-check using lsnrctl status LISTENER2011 that the instance has registered.

Note 3: It is crucial to use spaces between the various segments of the command as shown above (for example). Reason: the database agent in Oracle Clusterware currently determines whether the local_listener or remote_listener have been manually set by a string comparison operation. If the string looks like it is not manually altered, the agent will overwrite these parameters with the default values that it determines on instance startup. In order to prevent a reset of these parameters at instance startup and thereby make this setting persistent across instance starts, slight modifications in the string used for this parameter are required. ER 11772838 has been filed to allow for a more convenient mechanism.

Note 4: As the LOCAL_LISTENER parameter is a per instance parameter, perform this change on all nodes that the database is running on accordingly. 

Note 5: This example so far assumed that only one database (ORCL) is used in the system, with the SCAN name "cluster1" and now using "LISTENER2011", listening on port 2011, as the new node listener. Before the new node listener was created, the listener with the name "LISTENER" used to be the default node listener. This listener, listening on port 1521, has not been removed yet and can therefore now be used as a dedicated listener for additional databases added to the system for example. In order to ensure that those databases will use this listener, the LOCAL_LISTENER instance parameter should point to this listener as follows: 

• local_listener:(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=1521)))) 


Note 6: The clients' TNSNAMES.ora files do not need to be modified in this case, as the SCAN remains as the primary entry point for clients to connect to databases in the cluster. This is the beauty of SCAN.

With this change the following configuration has been established:

• The SCAN listener port remains on port 1541 (was: 1521)
• The node listener used by database ORCL is now called LISTENER2011, listening on port 2011
• In order for clients to be able to connect to this database, no change to their TNSNAMES.ora is required. They still use: 
  
    
  testscan1541 =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = cluster1)(PORT = 1541))
      (CONNECT_DATA =
        (SERVER = DEDICATED)
        (SERVICE_NAME = ORCL)
      )
    )
    

• Even, if more databases are added to the cluster, using the default node listener "LISTENER", still listening on port 1521 in this example, the client TNSNAMES.ora would not change. Again, this is the beauty of SCAN.

Using the node listeners as the primary entry point directly
Continuing the previous example, the following configuration is assumed for the next steps:

• The SCAN listener port remains on port 1541 - SCAN name is "cluster1"
• The node listener used by database ORCL is now called LISTENER2011, listening on port 2011
• The node listener used by database FOOBAR is called LISTENER, listening on port 1521

In order for clients to connect to the databases ORCL and FOOBAR, but not using SCAN, a TNSNAME.ora entry for each database must be used. The pre-Oracle 11g Rel. 2 RAC paradigm must be followed in this case. Hence, one typical TNSNAMES.ora entry for the example used here would look like the following:


ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 2011))
    (ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 2011))
    (ADDRESS = (PROTOCOL = TCP)(HOST = node...)(PORT = 2011))
    (ADDRESS = (PROTOCOL = TCP)(HOST = nodeN-vip)(PORT = 2011))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL)
    )
  )

FOOBAR =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = node...)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = nodeN-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = FOOBAR)
    )
  )

  
Each database (ORCL and FOOBAR) on the other hand must be adjusted to register with the local and remote listener(s) logically "assigned" to the respective database. This means forORCL's first instance:  


local_listener:(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=2011))))
remote_listener:(DESCRIPTION=(ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 2011))(ADDRESS = (PROTOCOL = TCP)(HOST = node...)(PORT = 2011))(ADDRESS = (PROTOCOL = TCP)(HOST = nodeN-vip)(PORT = 2011)))


For FOOBAR's first instance this means:  


local_listener:(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521))))
remote_listener:(DESCRIPTION=(ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = node...)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = nodeN-vip)(PORT = 1521))))

  
Note 1: Unlike when using SCAN, you can use a server side TNSNAMES.ora to resolve the local and remote listener parameters as it used to be recommended for pre-Oracle RAC 11g Release 2 databases. With Oracle RAC 11g Rel. 2, the use of SCAN would make this unnecessary.

Note 2: Avoiding the necessity to set parameters for each database and to change those every time the cluster and the databases change with respect to he number of nodes, is the reasonyou should use SCAN