Grid Infrastructure Single Client Access Name (SCAN) Explained (文档 ID 887522.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Exalogic Elastic Cloud X4-2 Half Rack
Information in this document applies to any platform.

PURPOSE

11gR2 Grid Infrastructure (CRS) introduced Single Client Access Name (SCAN) to simplify client access to database services, this article is going to explain whats SCAN and how it works.

SCOPE

Intended audience will be DBAs who is installing/upgrading to 11gR2 Grid Infrastructure or support analyst who is supporting stated product.

DETAILS

SCAN Concepts

• Single client access name (SCAN) is the virtual hostname to provide for all clients connecting to the cluster (as opposed to the vip hostnames in 10g and 11gR1).
• SCAN is a domain name registered to at least one and up to three IP addresses, either in the domain name service (DNS) or the Grid Naming Service (GNS).
• By default, the name used as the SCAN is also the name of the cluster and must be globally unique throughout your enterprise. The default value for the SCAN is based on the local node name. SCAN name must be at least one character long and no more than 15 characters in length, must be alphanumeric - cannot begin with a numeral and may contain hyphens (-). If you require a SCAN that is longer than 15 characters, then select an Advanced installation.
• For installation to succeed, the SCAN must resolve to at least one address.
• SCAN VIP addresses must be on the same subnet as virtual IP addresses and public IP addresses.
• Oracle strongly recommends that you do not configure SCAN VIP addresses in the hosts file. But if you use the hosts file to resolve SCAN name, you can have only one SCAN IP address.
• If hosts file is used to resolve SCAN hostname, you will receive Cluster Verification Utility failure at end of installation (see Note: 887471.1 for more details)
• For high availability and scalability, Oracle recommends that you configure the SCAN to use DNS Round Robin resolution to three addresses.
• Because the SCAN is associated with the cluster as a whole, rather than to a particular node, the SCAN makes it possible to add or remove nodes from the cluster without needing to reconfigure clients. It also adds location independence for the databases, so that client configuration does not have to depend on which nodes are running a particular database.
• Clients can continue to access the cluster in the same way as with previous releases, but Oracle recommends that clients accessing the cluster use the SCAN. Clients using the SCAN can also access the cluster using EZCONNECT.
• Grid Infrastructure will start local listener LISTENER on all nodes to listen on local VIP, and SCAN listener LISTENER_SCAN1 (up to three cluster wide) to listen on SCAN VIP(s); 11gR2 database by default will set local_listener to local LISTENER, and remote_listener to SCAN listener.
• SCAN listener will be running off GRID_HOME, and by default, in 11gR2 local listener will be running off GRID_HOME as well.

Common Questions Regarding SCAN

The following is a list of commonly asked questions regarding SCAN:

How can we configure the SCAN and SCAN listener?

During Typical installation, you are prompted to confirm the default Single Client Access Name (SCAN), which is used to connect to databases within the cluster irrespective of which nodes they are running on.  If you change the SCAN from the default, then the name that you use must be globally unique throughout your enterprise.

If the SCAN name resolves to one IP address, root script (root.sh or rootupgrade.sh) will create the number of SCAN VIP resources(ora.scan1.vip) and corresponding SCAN listener resource(ora.LISTENER_SCAN1.lsnr) depend on how many IP address the SCAN name resolves to, i.e.if the SCAN name resolves to two IP addresses, it will create two SCAN VIP resources and two corresponding SCAN listener resource.

SCAN VIP and the corresponding SCAN listener works like a pair, when SCAN VIP fails over to other node, the corresponding SCAN listener will also be failed over to the same node.

When SCAN VIP fails over happens, it will always select a node with least running SCAN VIP, i.e., if SCAN VIP runs on node1, node2 and node3 of a 4-node cluster, if node3 goes down, the SCAN VIP and corresponding SCAN listener will be failed over to node4 as the other two nodes already have one SCAN VIP running on each node.

Also we can use 'srvctl' to add/modify the scan resource and the listeners.  Please refer to "Real Application Clusters Admin and Deployment Guide" or Note 1053147.1 for more information.

Do we still need to configure local listeners on each node?

Yes, you would need to configure independent local listeners for each node.  SCAN listeners are not replacements for the node listeners.

A new set of cluster processes called scan listeners will run on three nodes in a cluster (or all nodes if there are less than 3).  If you have more than three nodes, regardless of the number of nodes you have, there will be at most three scan listeners.  The database registers with the SCAN listener through the remote listener parameter in the init.ora/spfile.  If any of these clustered processes fail, they are automatically restarted on a new node.

How does SCAN work ?

The following is the explanation given in Appendex D "Oracle Grid Infrastructure for a Cluster Installation Concepts" of the Oracle Grid Infrastructure Installation Guide:

"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 (Each scan listener keeps updated cluster load statistics) 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."

$ SRVCTL STATUS SCAN_LISTENER
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node TEST1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node TEST2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node TEST3

Instead of DNS or GNS, Can we use '/etc/hosts' to resolve SCAN?

Oracle strongly recommends that you do not configure SCAN VIP addresses in the hosts file. But if you use the hosts file to resolve SCAN name, you can have only one SCAN IP address.

If hosts file is used to resolve SCAN hostname, you will receive Cluster Verification Utility failure at end of installation (See NOTE 887471.1 for more details)

Can we use the previous method (Using VIP) for client connection?

Clients can continue to access the cluster in the same way as with previous releases. Vips are still used internally, and can still be used for connections. But Oracle strongly recommends that clients accessing the cluster use the SCAN. Clients using the SCAN can also access the cluster using EZCONNECT.

Is it mandatory to use SCAN?

It's highly recommended to use SCAN unless there's strong business reason preventing it from being used.

Is it supported to remove SCAN?

SCAN is an elementary part of 11gR2 Grid Infrastructure, it's not supported to remove SCAN.

Is it recommended to use COST feature?

As a Best Practice, Oracle recommends using the COST feature to restrict instance registration with SCAN listeners as part of your standard listener configuration.  Refer to note 1340831.1 for more details.

Demo

Sample TNS entry for SCAN

TEST.ORACLE.COM = (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=SCAN-TEST.ORACLE.COM)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=11GR2TEST.ORACLE.COM)))

Sample TNS Entry without SCAN

TEST.ORACLE.COM = (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=TEST1-vip.ORACLE.COM)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=TEST2-vip.ORACLE.COM)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=11GR2TEST.ORACLE.COM)))

REFERENCES

NOTE:1053147.1 - 11gR2 Clusterware and Grid Home - What You Need to Know
NOTE:887471.1 - PRVF-4664 PRVF-4657: Found inconsistent name resolution entries for SCAN name
NOTE:972500.1 - How to Modify SCAN Setting or SCAN Listener Port after Installation
NOTE:975457.1 - How to Troubleshoot Connectivity Issue with 11gR2 SCAN Name