SCAN Single Client Access Name
SCAN is a simple and beautiful concept introduced in Oracle Clusterware (Grid Infrastructure) 11.2. To appreciate the convinience that SCAN brings in , it is essentail to understand how the client connection works in earlier releases and what are the drawbacks of them.
How Client Connection to a RAC database (real application cluster database) works in pre-11gR2 releases:
In a simple scenario,
On the RAC Server side : All RAC nodes have their own VIP(Virutal IPs).On Each nodes there is a listener listening on Virtual IP.
Each instance on the Server is registered with listener on the node it runs and with ALL other listeners in the cluster.That means at any given time all the listeners are aware of all instances in the cluster and load conditions of each of those instances.
On the Client accessing the RAC DB:
The goals cleint have while establishing a connection are :
- Connection attempt should be made to nodes in a round robin manner from each client.
- If one node is not available , connection should go to another available node.
- Connection should reach the least loaded node.
How these goals are achieved?
On the client side there is a tnsname.ora. (Or the JDBC connect string used to connect RAC database ).The tnsname.ora conatins all VIPs in its address list. For example in the case of sixteen node rac a sample tnsnames.ora would contan entres like.
Now this Tnsnames entry , along with server side setting helps to acheive all the three goals a client wishes.Let us see how it is.
A client initates an connection attempt by specifying RACDB as its connect identifier. If there is a load_balance ON on the client side , TNS would select one of the addresses randomly selected from the above list of node vips – met goal 1 above. If the selected address is not availble, (In case if node down) the connection attempt would be made to another address – met goal 2 above.(Note: incase if a node1 is down, node1-vip would have move to another node and would send reset signal when a connection is attempted to it).
On Server,
Once the connection request reaches one of the listeners (for example the listener on node10-vip) , that listener will decide which is the least loaded instance for the requested connection and then direct the client to the listener running on the desired node. Ie for example client attempts to connect using “RACDB” , The address selected is of node10-vip. The listener on node10-vip knows (by service updates) instance on node5 is least loaded. The listener on node10-vip directs the client to listener on node5-vip. Client connect to node5-vip listener and that listener hand off connection to rdbms instance node5.
This is what happens in the case of pre-11gR2 releases.
What are the advantages of using SCAN (Single client access name)?
First let us look into the drawbacks of existing mechanism.
When a node added or removed from cluster:Think about scenario when you have 16 nodes in the cluster. As described above the tnsname.ora should contain 16 address entries. Assume that there are several clients that keeps tnsname.ora in various locations. If you are to add a node or remove a node from the clsuter, the same change has to be made in all tnsnames.ora files in various different locations.
When Using EZ connect
Oracle now offers a method called EZ Connect for client connections. Using EZ connect allows to connect without having a tnsnames.ora entry.An example EZ Connect connection will like the following.
sqlplus system/oracle@node1-vip1:1521/orcl
However here we specify only one node.(which indicate we are not able to meet some of the goals mentioned above a client connection has)
What is the SCAN (Single Client Access Name) and how it addresses above problems?
First of all When you use SCAN Name to connect to a RAC database you would be specifying on one name.(in tnsnames or in EZ connect or in JDBC connect string).This is the unique name associated with each of the rac cluster.
An example of SCAN connection will look like
in tnsnames.ora it will be just like the following irrespective of the number or nodes in the cluster.
RACDB= (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = SCAN_NAME)(PORT = 1521))That is only one entry irrespecitive of number of nodes. Even if the nodes are added or removed this does not change as node specific entries are not there.
An EZ connect will look like below when using SCAN Access.
./sqlplus system/oracle@SCAN_NAME:1521/orcl
(this is still capable of provide all desired goals of connection attempt)
A JDBC Thin connect string also need to contain only just SCAN_NAME instead of several node VIPS.
Now what is this SCAN Name:
From an Networking perspective, it is just a name defined in the DNS. However DNS is configured in such a way that this name would resolve to three different IPs.When ever there is a request from Clients these IPs would be provided in round robin.
From a Clusterware perspective, clusterware uses these three IPs to accept the client connections. ie client connections are no longer directed to the node-vips (they still exists) when SCAN name is used. Instead they reach the SCAN IPs first. The three SCAN IPs can be considered as another SET OF FLOATING VIPs. These three IPs can be bought online on any of the three nodes in a cluster(decided by Clusterware usually).
How the SCAN Works:
- Clusterware brings SCAN IPs online on any of the three nodes in the cluster
- Clusterware starts three listeners (known as SCAN Listeners) also on these nodes. (these are technically same as any other lister, but listens on scan ip)
- All instances in the clsuter will have remote_listener parameter pointed to the scan_name:port example for remote_listener *.remote_listener=scan_name:1521
How the Client connection works thru SCAN?
Client connection attempt, based on the IP provide from DNS, reaches one the SCAN LIstner. SCAN Listener is aware of load and availability conditions of all Instances in the
cluster.It direct the client to most sutiable instance. This is done by directing the client to the Listener on node-vip of the most suitable instance. Once the client connection reaches the local listerner it hands off the connection to database.
Advantages of SCAN :Since it uses only one name for clsuter , node addition/removal does not need any change in the tnsname. Easier option of using just one name in EZ connect string. Easier option of using just one name in the JDBC connect string.
Client side load balancing is acheived by connecting to either of the three scan ips. Server side load balancing is done by SCAN Listeners who are aware of the load conditions of instances.So while meeting all the desired goals of client connection attempts, scan provides ease of managing.
Does SCAN introduces any new concerns: (draw back of SCAN?)
Assume there is DNS issue which results in a DNS hang. What will be the result?Ofcourse the clients will not get any IP back from DNS for the scan_name and client connection attemps would be just hung.
Why this become more severe in the case of scan. SCAN which uses a three ip resolution method can not be exactly handled by the /etc/hosts name resolution. In the case of VIPS(which resolve to only one IP) it was possible to handle this nodevip-name resolution by /etc/hosts itself.(true, one more file to manage)
Now assuming that if the SCAN Name is somehow locally resolved by /etc/hosts/. Would that be just enough? Not exactly. Because the scan listener would direct the client connection to one of the node local listeners. That means the SCAN listener would just send back the client a VIP_NAME. (for example the node5-vip). The client need to still resolve this VIP name too. So either this need to be resolved at client local /etc/hosts or from DNS.
This kind of scenarios (which includes a DNS hang) are rare, but can happen at any environment , especially if the name resolution for node vips only not working in DNS, a
common user will be clueless on what is going on. Becuase a tnsping to the scan name (or tns alias) will work quick, only connection would be hung.
Common Errors Seen with SCAN and Real application clusters.
ALL illustrations below uses EZ connect. The issues would be more or less simiar with TNS Entry or even JDBC connect string.
(1) /sqlplus system/oracle@scan_name:1521/test
Error :ORA-12514: TNS:listener does not currently know of service requested in connect descriptor When connecting using scan listener.Cause :This simply indicate the SCAN LISTENER is not aware of the database service test.
Diagnosing and Solution:
on the RAC server run the following to identify on which node the scan listeners are running.
This output shows on which node each of the scan listener listens.
Now check for the services known to each of them on respective nodes.
LSNRCTL for Linux: Version 11.2.0.2.0 – Production on 01-JUL-2011 16:21:56
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3)))STATUS of the LISTENER ————————Alias LISTENER_SCAN3Version TNSLSNR for Linux: Version 11.2.0.2.0 – ProductionStart Date 29-JUN-2011 18:19:20Uptime 1 days 22 hr. 2 min. 35 secTrace Level offSecurity ON: Local OS AuthenticationSNMP OFFListener Parameter File /grid/64bit/crs112/network/admin/listener.oraListener Log File /grid/64bit/crs112/log/diag/tnslsnr/racnode1/listener_scan3/alert/log.xmlListening Endpoints Summary… (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN3))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.10.19.56)(PORT=1521)))Services Summary … Service “orcl” has 3 instance(s). Instance “orcl1″, status READY, has 1 handler(s) for this service … Instance “orcl2″, status READY, has 1 handler(s) for this service … Instance “orcl3″, status READY, has 1 handler(s) for this service …Service “orclXDB” has 3 instance(s). Instance “orcl1″, status READY, has 1 handler(s) for this service … Instance “orcl2″, status READY, has 1 handler(s) for this service … Instance “orcl3″, status READY, has 1 handler(s) for this service…The command completed successfully
Now this output shows the service name used in the connect string “test” is not registerd with SCAN_Listener and that results in error.
Solution: Login to instances of test database and make sure the following parameter is set.
*.remote_listener = scan_name:1521
This will make sure instances are registered with SCAN Listeners.
(2) Error TNS-12545: Connect failed because target host or object does not exist while connecting via scan listener.
However tnsping to scan listener works fine.
Cause : The node vip names are not resolving on the client machine.
Diagnosing and Solution:
Attempt to connect all node listeners on the rac cluster. Ping and make sure all NODE VIPS and listeners are accessible from the client machine.
When a client reaches the scan listener, scan listener simply divert the client to suitable node,by providing the vip name of that node. If that name does not resolve on
the client machine above error will be the result.
Solution: Make sure all node vip names are resolving properly on the client machines. (Either make necessary changes on DNS or add the entries to /etc/hosts)
SCAN FAQ?
1. Is it possible to have more than three SCAN IPS?
Ans: No, number of scan IPs is limited to three.
2. Can Oracle 11.2 be installed without a scan name?
Ans: Oracle 11.2 installation screens of OUI needs a scan name. So it can not be installed without a scan name. However if SCAN Name is not available from DNS, a dummy entry in the /etc/hosts of all node would be sufficient to complete the installation.
3. Oracle 11.2 Clusterware , can it be used without SCAN? Yes , Oracle 11.2 also can be used without scan as it used to be in the earlier versions of 10g or 11.1. In this case still connections can be made via node vips and instances needs to be registered with Node listeners as it used to be in 11.1 or 10g.
4. Can we have more than one local listener per node with scan? Yes , more than one local listener (for example one local listener per database) is possible with scan. Still the connections can be made via Scan. This is because when PMON of each database registers with scan it will inform scan about the local listener information too. So that enables scan listener to hand off connection to appropriate local listener.