The SCAN is an essential part of Database configuration. So, by default, the REMOTE_LISTENER parameter is set to the SCAN, assuming that the Database is created using standard Oracle tools. This enables the instances to register with the SCAN Listeners as remote listeners to provide information on what services are being provided by the instance, the current load, and a recommendation on how many incoming connections should be directed to the instance.

In this context, you must set the LOCAL_LISTENER parameter to the node-VIP. If you need fully qualified domain names, then ensure that the LOCAL_LISTENER parameter is set to the fully qualified domain name. By default, a node listener is created on each node in the cluster during cluster configuration. With Oracle Grid Infrastructure, the node listener runs out of the Oracle Grid Infrastructure home and listens on the node-VIP using the specified port. The default port is 1521.

Unlike in earlier Database versions, Oracle does not recommend to set your REMOTE_LISTENER parameter to a server side TNSNAMES alias that resolves the host to the SCAN in the address list entry, for example, HOST=sales1-scan. Instead, you must use the simplified SCAN:port syntax as shown in the following table that shows typical setting for a LOCAL_LISTENER and REMOTE_LISTENER:

Example

This example assumes an Oracle client using a default TNSNAMES.ora file:

ORCLservice =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = sales1-scan.example.com)(PORT = 1521))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = MyORCLservice)))

To successfully use the SCAN to connect to an Oracle RAC Database in the cluster depends on the following two factors:

• Ability of the client to understand and use the SCAN

• The correct configuration of the REMOTE_LISTENER parameter setting in the Database

If the version of the Oracle Client connecting to the Database and the Oracle Database version used are both Oracle Database 11g Release 2, and the default configuration is used as described in the preceding sections, then typically you do not need to make any change to the system.

If both the Oracle Client version and the version of the Oracle Database that the client is connecting to are earlier than Oracle Database 11g Release 2, then typically you do not need to make any change to the system. In this case, the client uses a TNS connect descriptor that resolves to the node-VIPs of the cluster, while Oracle Database uses a REMOTE_LISTENER entry pointing to the node-VIPs. The disadvantage of this configuration is that the SCAN is not used and therefore every time the cluster changes in the back end, the clients are exposed to changes.

If you are using Oracle Database 11g Release 2, but the clients are on an earlier version of the Database, then you must change the Oracle client, or the Oracle Database REMOTE_LISTENER parameter settings, or both accordingly. You must consider the following cases in such a scenario:

If you are using a client earlier than Oracle Database 11g Release 2, then you cannot fully benefit from the advantages of the SCAN because the Oracle Client cannot handle a set of three IP addresses returned by the DNS for the SCAN. Instead, it tries to connect to only the first address returned in the list and ignores the other two addresses. If the SCAN Listener listening on this specific IP address is not available or the IP address itself is not available, then the connection fails. To ensure load balancing and connection failover with clients earlier than Oracle Database 11g Release 2, you must update the TNSNAMES.ora file of the client, so that it uses three address lines, where each address line resolves to one of the SCAN VIPs. The following example shows a sample TNSNAMES.ora file for a client earlier than Oracle Database 11g Release 2:

sales.example.com =(DESCRIPTION=
(ADDRESS_LIST= (LOAD_BALANCE=on)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=133.22.67.192)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=133.22.67.193)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=133.22.67.194)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME= salesservice.example.com)))

If you have a Maximum Availability Architecture (MAA) environment implemented, in which you use Oracle RAC for both your primary and standby Databases that are synchronized using Oracle Data Guard, then using the SCAN provides a simplified TNSNAMES configuration that a client can use to connect to the Database, independent of whether the primary or standby Database is the currently active Database.

To use this simplified configuration, Oracle Database 11g Release 2 introduced the following two SQL*Net parameters that can be used for connection strings of individual clients:

• The CONNECT_TIMEOUT parameter

  It specifies the timeout duration in seconds for a client to establish an Oracle Net connection to an Oracle Database. This parameter overrides the SQLNET.OUTBOUT_CONNECT_TIMEOUT parameter in the SQLNET.ORA file.

• The RETRY_COUNT parameter

  It specifies the number of times an ADDRESS_LIST is traversed before the connection attempt is terminated.

Using these two parameters, both the SCANs, the one on the primary site and the one on the standby site, can be used in the client connection strings. Also, if the randomly selected address points to the site that is not currently active, then the timeout enables the connection request to failover before the client waits for an unreasonably long time. The following example shows a sample TNSNAMES.ORA entry for a MAA environment:

sales.example.com =(DESCRIPTION= (CONNECT_TIMEOUT=10)(RETRY_COUNT=3)
(ADDRESS_LIST= (LOAD_BALANCE=on)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-scan)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME= salesservice.example.com)))

If you use Oracle Connection Manager (CMAN) with your Oracle RAC Database, then the REMOTE_LISTENER parameter for the Oracle RAC instances must include the CMAN server, so that the CMAN server receives load balancing related information and can load balance connections across the available instances. The easiest way to achieve this is to add the CMAN server as an entry to the REMOTE_LISTENER parameter of the Databases that clients want to connect to through CMAN. You must also remove the SCAN from the TNSNAMES connect descriptor of the clients and configure the CMAN server. The following example shows a server-side TNSNAMES.ora example entry when you use CMAN:

SQL> show parameters listener
NAME                TYPE         VALUE
-------------------------- ----------- ------------------------------
listener_networks   string
local_listener      string      (DESCRIPTION=(ADDRESS_LIST=
                                (ADDRESS=(PROTOCOL=TCP)
                                (HOST=148.87.58.109)(PORT=1521))))
remote_listener     string      stscan3.oracle.com:1521,(DESCRIPTION=
                                (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
                                (HOST=CMANserver)(PORT=1521))))