SCAN Concepts

a) Single client access name (SCAN) is the virtual hostname to provide for all clients connect
ing to the cluster (as opposed to the VIP hostnames in 10g and 11gR1).
b) 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).
c) 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.
d) For installation to succeed, the SCAN must resolve to at least one address.
e) SCAN VIP addresses must be on the same subnet as virtual IP addresses and public IP addre
sses.
f) 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.
g) If the hosts file is used to resolve SCAN hostname, you will receive Cluster Verification
Utility failure at end of installation.
h) For high availability and scalability, Oracle recommends that you configure the SCAN to use
DNS Round Robin resolution to three addresses.
i) 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 conf
iguration does not have to depend on which nodes are running a particular database.
j) 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.
k) 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.
l) SCAN listener will be running off GRID_HOME, and by default, in 11gR2 local listener will
be running off GRID_HOME as well.
m) In 12c, SCAN supports multiple subnets in the cluster (one SCAN per subnet)

Common Interview 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 addresses 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.

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 no
des 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 Appendix 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 SC
AN 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 a 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 the installation.

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.

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=TE
ST2-vip.ORACLE.COM)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=11GR2TEST.
ORACLE.COM)))

How does SCAN replace TAF in a RAC? Should I use SCAN instead of manual load balancing?

Answer: According to reliable sources on the web, SCAN provides a single domain name via
DNS), allowing and-users to address a RAC cluster as-if it were a single IP address. SCAN works
by replacing a hostname or IP list with virtual IP addresses (VIP).

Because SCAN determines the actual node and listener which accepts the connection, SCAN
provides location independence for the databases. A SCAN database connection does not require
any details about a particular node on instance. SCAN is part of the 11g release 2 movement
toward "RAC Virtualization". Virtualization is great for some RAC shops, not so good for others.

Expert Note: SCAN is an automatic load balancing tool that uses a relatively primitive least-rec
ently-loaded algorithm. Most Fortune 50 mission critical RAC systems will not use an automated
load balancer in favor of intelligent RAC load balancing., where you direct like-minded trans
actions to like-minded nodes. This approach greatly reduces the load on the cache fusion payer
because less blocks must be sent across the RAC interconnect.

According to Oracle, there are two benefits for SCAN:

Fast RAC failover: If a node fails, Oracle detects the loss of connection to the VIP and redirects
new connects to the surviving VIP's. This is an alternative to the transparent application failover.
(TAF) for automatic load balancing.

Easier maintenance for Grid RAC systems: For Grid systems that gen-in/out blade servers freque
ntly, SCAN offers easier change control for the DBA. As RAC nodes are added or deleted, the
DBA does not have to change the configuration files to reflect the current list of RAC node IP addr
esses/hostnames. In a nutshell, SCAN allows a single cluster alias for all instances in the cluster.
Configuring RAC to use SCAN
The set-up for SCAN is implemented as follows:
STEP 1 - Add a new DNS entry for SCAN (e.g. /etc/hosts). This will create a single DNS domain
name that resolves to all of the IP addresses in your RAC cluster (one for each node). This will use
a round-robin algorithm
root> cat /etc/hosts
myscan.mydomain.com IN A 122.22.22.22 IN A 122.22.22.23 IN A 122.22.22.24

STEP 2 - Create a SCAN VIP for each IP address in step 1.

STEP 3 - Create a SCAN listener for each VIP that was created in step 2.

STEP 4 - Change the tnsnames.ora file. This entry will point SCAN to the single DNS hostname
created in step 1. Prior to the introduction of SCAN (11g r1 and earlier using TAF or intelligent
load balancing ), the tnsnames.ora file contained a list of hostnames, one for each node in the
cluster:
SCANDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = myscan1.mydomain.com)(PORT = 1522))
(ADDRESS = (PROTOCOL = TCP)(HOST = myscan2.mydomain.com)(PORT = 1522))
(ADDRESS = (PROTOCOL = TCP)(HOST = myscan3.mydomain.com)(PORT = 1522))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCANDB)
)
)

STEP 5 - Set the remote_listener and local_listener parameters: You want to set your remote_list
ener parameter to point to a tnsnames.ora entry for SCAN as defined in step 4.
remote_listener=myscan.mydomain.com:1522

The SCAN listener for RAC

This single domain addressing is implemented via a "scan listener" and the status can be checked
with the standard lsnrctl command, passing the SCAN listener name as an argument:
oracle> lsnrctl service
oracle> lsnrctl stat myscan_listener
LSNRCTL for UNIX: Version 11.2.0.1.0 . .
Connect (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_MYSCAN1)))

STATUS of the LISTENER . . .

Server control commands for SCAN

According to Karen Reidford, there are several new server control (srvctl) commands for SCAN:
New SRVCTL Command What it does
srvctl config scan Shows the current SCAN configuration
srvctl config scan_listener Shows the existence and port numbers for the
SCAN listeners
srvctl add scan -n cluster01-scan Adds new SCAN information for a cluster
srvctl remove scan -f Removes SCAN information
srvctl add scan_listener Adds a new SCAN listener for a cluster on the
default port of 1521
srvctl add scan_listener -p 65001 ## non default Adds a new SCAN listener on a different port
port number ##
srvctl remove scan_listener Removes the SCAN listener
srvctl modify scan -n cluster_scan
srvctl modify scan_listener -u
Modifies SCAN information (used when
changing SCAN to DNS after initially using
/etc/hosts)
Modifies the SCAN listener information to
match the new SCAN VIP information from the
modify scan command

The IP addresses associated with the SCAN VIP resources are initially set when the SCAN resour
ces are created. Any changes to the DNS entry for the SCAN are not automatically propagated to
the clusterware and need to be done manually. This applies only to installations that are not using
GNS. The information in this note can also be helpful in cases where SCAN was originally config
ured with just one address and is now being expanded to accommodate three IP addresses.

Below is an example using the following configuration:

The name of the SCAN is scan.example.com
subnet of the public network is 10.100.10.0
netmask for the public network is 255.255.255.0
name of the public interface is eth1
old IP addresses: 10.100.10.81, 10.100.10.82 & 10.100.10.83
new IP addresses: 10.100.10.121, 10.100.10.122 & 10.100.10.123

Stopping&starting the SCAN resources can be done by the grid user, however, the ‘srvctl modify
scan’ cmd must be executed by the root user, so it’s practical to execute all steps as the root user.
Modifying SCAN VIP resources
1. Before the SCAN VIPs can be changed, the entry for the SCAN name on the Domain Name
Server (DNS) needs to be updated with the new IP addresses. This usually will be done by a netw
ork administrator. To check the current setting, the following cmd can be used:
# nslookup [scan_name]
A lookup of the SCAN on the DNS server shows that the entry has already been updated with the
new IP addresses:
$ nslookup scan.example.com
Server: dns1.example.com
Address: 10.100.10.70#53
Name: scan.example.com
Address: 10.100.10.123
Name: scan.example.com
Address: 10.100.10.122
Name: scan.example.com
Address: 10.100.10.121

2. To check the current IP address(es) of the SCAN VIPs, run the following cmds as the root user:
# $GRID_HOME/bin/srvctl config scan
The SCAN VIP resources will still show the old IP addresses:
# $GRID_HOME/bin/srvctl config scan
SCAN name: scan, Network: 1/10.100.10.0/255.255.255.0/eth1
SCAN VIP name: scan1, IP: /scan.example.com/10.100.10.81
SCAN VIP name: scan2, IP: /scan.example.com/10.100.10.82
SCAN VIP name: scan3, IP: /scan.example.com/10.100.10.83

3. Stop the SCAN listeners and SCAN as root user.

# GRID_HOME/bin/srvctl stop scan_listener
# GRID_HOME/bin/srvctl stop scan

Verify if SCAN and SCAN listener has stopped.

# $GRID_HOME/bin/srvctl status scan
SCAN VIP scan1 is enabled
SCAN VIP scan1 is not running
SCAN VIP scan2 is enabled
SCAN VIP scan2 is not running
SCAN VIP scan3 is enabled
SCAN VIP scan3 is not running
# $GRID_HOME/bin/srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is not running
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is not running
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is not running

4. Next refresh the SCAN VIPs with the new IP addresses from the DNS entry:
# $GRID_HOME/bin/srvctl modify scan -n [scan_name]
For example :
# $GRID_HOME/bin/srvctl modify scan -n scan.example.com

5. To check if the SCAN VIPs have been changed, run the following cmd, it should now show the
new IP addresses.
# GRID_HOME/bin/srvctl config scan
SCAN name: scan, Network: 1/10.100.10.0/255.255.255.0/eth1
SCAN VIP name: scan1, IP: /scan.example.com/10.100.10.121
SCAN VIP name: scan2, IP: /scan.example.com/10.100.10.122
SCAN VIP name: scan3, IP: /scan.example.com/10.100.10.123

6. Restart SCAN & SCAN listener:

# GRID_HOME/bin/srvctl start scan
# GRID_HOME/bin/srvctl start scan_listener

7. If the number of SCAN VIPs has changed, the SCAN listener needs to be updated:
# GRID_HOME/bin/srvctl modify scan_listener -u

NOTE: If the SCAN VIPs are being changed because of a change of the subnet of the public netw
ork additional changes may be required , e.g. the node VIPs and the network resource (ora.net1.
network). For more information please refer to Document 276434.1

I have configured 3 SCANs using DNS, you can use GNS as well if no DNS in your network
environment! In Easy Words, SCAN is another layer over VIP, SCAN is basically a name and
gives you the flexibility to be little independent of the IPs, Once your client Access the SCAN
Name, DNS will resolve it to Assigned IPs then connection will be routed to one of the SCAN
Listeners which further routs the connection to one of the VIP! Enjoy more flexibility, Adding new
nodes in Grid is not any issue, 3 SCANs recommended to be more flexible and redundant, Client
connection strings are not required to change after adding/removing nodes from Grid/RAC.

* Elaborations*******************

#######################Configuration Before SCAN#########################

Number of RAC Nodes: 8
Physical IPs: 8, One for each node
Private IPs: at least 8, One for each node (You can have two for each for redundancy)
Virtual IPs: 8, One assigned to each node ... Word "assigned" is important
Number of VIP Listeners: 8, Each Bound to certain Node ... word "bound"/"assigned"
Client Connection String: Mentioning address of all 8 VIP Listeners (Failover etc.)

Simplest Event: Add 4 new Nodes or Remove 4 Nodes

Required Action: Update the Client connection string on all clients
Connection Establishment: Client sends request to one of VIP Listeners mentioned in client
connection string, if failed then client will send request on another VIP address until the
connection is successful. So client sending requests directly to VIP listeners specific/bound to VIP
on each node.

#######################Configuration After SCAN##########################

* SCAN*************************************

SCAN: Single Client Access Name -- Allowing client to access whole cluster/grid through one
name, rather specifying all VIP addresses individually
SCAN Requirement: To be able to get SCAN Functionality, We need some service through which
one name is resolved to multiple IPs/hosts. This is what we often call "DNS", Domain name
service or if you don't have DNS in your environment then you can use Oracle's "GNS (Grid
Naming Service)"

SCAN Implementation/Configuration: In Our DNS We defined a ScanName and assigned three

Virtual IPs e.g (OraProdScan=X.X.X.5, X.X.X.6 and X.X.X.7), Now when you do nslookup Ora
ProdScan from your client it will give you list of three IPs specified as above and important thing,
every time you do nslookup it will give you the IP addresses in round robin, So every request to
resolve the OraProdScan name will give different IP every time. One kind of load balancing at
first place to reach to SCAN Listener so requests will be distributed on available SCAN Listeners.

SCAN Usage: During Oracle Grid Installation, Specify mentioned IPs, Each VIP Listener on each
node will register itself will Every SCAN Listener on whatever node the SCAN Listener is
running.

Number of RAC Nodes: 8

Physical IPs: 8, One for each node
Private IPs: at least 8, One for each node (You can have two for each for redundancy)
Virtual IPs: 8, One assigned to each node ... Word "assigned" is important
Number of VIP Listeners: 8, Each Bound to certain Node ... word "bound"/"assigned"
Number of SCAN Listeners: 3, Grid will decide which nodes SCAN Listeners will be Allocated
Client Connection String: Mentioning the name of SCAN "OraProdScan"

Simplest Event: Add 4 new Nodes or Remove 4 Nodes

Required Action: No update required.
Connection Establishment: Client sends request to DNS using SCAN Name "OraProdScan", DNS
will return one of three IPs, Client Sends request on that IP to the SCAN Listener, the SCAN
Listener will route the request to one of the VIP Listeners among 8 VIP listeners in this case
because each VIP listener has already registered itself with every SCAN Listener. Finally direct
connection is established between client and one of the VIP Listeners.
You see flexibility, adding/removing as many nodes in Grid/RAC doesn't require any change.
Hope i have answered all questions, it was long post, if i still have missed anything please let me
know!

Que#1: Will three SCAN listeners have same same port to listen?
ANS: Yes all three Scan Listeners will have same port and you can choose the port and the port
will be different than the port used for VIP listeners. :-) Can't Share the port# which i used in my
production.
Que#2: Three SCAN listeners take the request parallel?
ANS: Yes three Scan listeners will run in parallel and accept requests, DNS will route request to
one of the SCAN Listener.
Que#3: So from 11.2 onwards we are not using VIP?
ANS: VIPs still exists on each node, But we dont use VIPs in our client connection string instead
we we use one SCAN-Name.

I would recommend to you read my previous post again carefully and now i ll give an example
below to explain in detail, Hope i ll be able to bring you on same page!

Que#1: It does seem VIPs are redudent in that case?

ANS: There is difference between VIP and SCAN Listener, Let me try to explain and hope the
example at the end will help to understand in more detail, First difference is VIP is always bound
to a node and each node will specifically have one VIP Listener Where as Grid Services will start
the SCAN Listener on any node e.g if you have three SCAN Listener and 2/3 RAC Nodes then it
may be the case that 2 SCAN Listeners in one node and 1 SCAN Listerner on second node where
as third node doesn't have any SCAN Listerner. For VIPs if a certain node is offline then that VIP
will not be available in Cluster where as if certain node is offline then Cluster will relocate the
SCAN to other surviving nodes.

Advantage of SCAN: Previously we specified all the VIPs in our client connections but now you
need to specify only one "SCAN Name" in your client address. If you Add/Remove Nodes in your
RAC then you dont need to update your client connection strings, The only change will be done in
DNS.