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 seemsto 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 standarddatabase 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 needsto 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 databaseservices 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 portsfor 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 configuredaccordingly using the following configuration:remote_listener: cluster1:1521local_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 addresseddirectly, 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 onlyNote 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_SCAN1Get the port of the scan listener: lsnrctl status LISTENER_SCAN1 returns: 1521Change the port of the SCAN listener: srvctl modify scan_listener -p 1541 new port 1541Restart the SCAN listener: srvctl stop scan_listener followed by srvctl start scan_listener Double-check using lsnrctl status LISTENER_SCAN1 - this should show port 1541Note 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 withthe 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 1521In 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 portsSo 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 sameIP, 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 advancedconfigurations. 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 thislistener, 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 OracleClusterware 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 thatit 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 hasbeen 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 orderto 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 2011In 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 directlyContinuing 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 2011The node listener used by database FOOBAR is called LISTENER, listening on port 1521In 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 theexample used here would look like the followina5d9g: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 SCANwould 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 |
转到底部
