Oracle Single Client Access Name (SCAN)

Single Client Access Name (SCAN) is a feature used in Oracle Real Application Clusters environments that provides a single name for clients to access any Oracle Database running in a cluster. 

The benefit is that the client’s connect information does not need to change if you add or remove nodes or databases in the cluster. 

SCAN was first introduced with Oracle Real Application Clusters (RAC) 11g Release 2 and provides additional functionality in Oracle RAC 12c. Having a single name to access the cluster to connect to a database in this cluster allows clients to use EZConnect and the simple JDBC thin URL to access any database running in the cluster, independently of the number of databases or servers running in the cluster and regardless on which server(s) in the cluster the requested database is actually active. 

EZconnet sqlplus system/oracle123@sales-scan:1521/oltp
JDBC connect jdbc:oracle:thin:@sales-scan:1521/oltp

Network Requirements for Using SCAN

The default SCAN configuration is defined during the installation of Oracle Grid Infrastructure that is distributed with Oracle Database 11g Release 2 or higher. 

Oracle Grid Infrastructure is a single Oracle Home that contains Oracle Clusterware and Oracle Automatic Storage Management.

You must install Oracle Grid Infrastructure first in order to use Oracle RAC 11g Release 2 or higher.

There are 2 options for defining the SCAN:

1. Define a SCAN using the corporate DNS (Domain Name Service)
2. Define a SCAN using the Oracle Grid Naming Service (GNS)

SCAN Configuration with Oracle Grid Infrastructure.

During cluster configuration, several resources are created in the cluster for SCAN. For each of the 3 IP addresses that the SCAN resolves to, a SCAN VIP resource is created and a SCAN Listener is created. The SCAN Listener is dependent on the SCAN VIP and the 3 SCAN VIPs (along with their associated listeners) will be dispersed across the cluster. This means, each pair of resources (SCAN VIP and Listener) will be started on a different server in the cluster, assuming the cluster consists of three or more nodes.

In case, a 2-node-cluster is used (for which 3 IPs are still recommended for simplification reasons), one server in the cluster will host two sets of SCAN resources under normal operations. If the node on which a SCAN VIP is running fails, the SCAN VIP and its associated listener will fail over to another node in the cluster. If by means of such a failure the number of available servers in the cluster becomes less than three, one server would again host two sets of SCAN resources.

[grid@mynode] srvctl config scan_listener

SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521
SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521
SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521

[grid@mynode] srvctl config scan

SCAN name: sales1-scan, Network: 1/198.162.80.0/255.255.252.0/
SCAN VIP name: scan1, IP: /sales-scan.example.com/198.162.80.10
SCAN VIP name: scan2, IP: /sales-scan.example.com/198.162.80.11
SCAN VIP name: scan3, IP: /sales-scan.example.com/198.162.80.12

Enhancements require changes in the configuration of the SCAN and SCAN_LISTENER:

[grid@mynode]$ srvctl config scan

SCAN name: sales-scan.example.com, Network: 1
Subnet IPv4: 198.162.80.0/255.255.252.0/eth0
Subnet IPv6:
SCAN 0 IPv4 VIP: 198.162.80.12
SCAN name: sales-scan.example.com, Network: 1
Subnet IPv4: 198.162.80.0/255.255.252.0/eth0
Subnet IPv6:
SCAN 1 IPv4 VIP: 198.162.80.11
SCAN name: sales1-scan.example.com, Network: 1
Subnet IPv4: 198.162.80.0/255.255.252.0/eth0
Subnet IPv6:
SCAN 2 IPv4 VIP: 198.162.80.10

[grid@mynode]$ srvctl config scan_listener

SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521
Registration invited nodes:
Registration invited subnets:
SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521
Registration invited nodes:
Registration invited subnets:
SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521
Registration invited nodes:
Registration invited subnets

Oracle Database Configuration Using SCAN

SCAN is an essential part of the Oracle RAC database configuration and therefore the REMOTE_LISTENER parameter is set to the SCAN per default, assuming that the database is created using standard Oracle tools (e.g. the formerly mentioned
DBCA).

This allows 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, the LOCAL_LISTENER parameter must be considered. The LOCAL_LISTENER parameter should be set to the node-VIP. If you need fully qualified domain names, ensure that LOCAL_LISTENER is set to the fully qualified domain name (e.g. node-VIP.example.com). 

SQL> show parameter listener

NAME                     TYPE                   VALUE
-------------------------- ----------- ------------------------------
local_listener          string                 (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=198.162.80.98)(PORT=1521))))

remote_listener      string                  sales-scan.example.com:1521

Client Load Balancing using SCAN

For clients connecting using Oracle SQL*Net , three IP addresses will be received by the client by resolving the SCAN name through DNS. 

The client will then go through the list it receives from the DNS and try connecting through one of the IPs received. If the client receives an error, it will try the other addresses before returning an error to the user or application. This is similar to how client connection failover works in previous releases when an address list is provided in the client connection string.

When a SCAN Listener receives a connection request, the SCAN Listener will check for the least loaded instance providing the requested service. It will then re-direct the connection request to the local listener on the node where the least loaded instance is running. Subsequently, the client will be given the address of the local listener. The local listener will finally create the connection to the database instance.

SCAN configuration using DNS (Domain Name Service)

For this you need to have a DNS entry with one single name that resolves to 3 IP addresses using a round robin algorithm. The IP addresses must be on the same subnet as your default public network in the cluster (In 12c R1 SCAN would support multiple subnets).

SCAN configuration using GNS (Grid Name Service)

In this case Oracle assumes you use some form of dynamic IP assignment on your public network, so you just need to mention the SCAN name and 3 IPs will be acquired from either a DHCP service or SLAAC when using IPv6 based IP address.

Round Robin Algorithm

Round-robin on DNS level allows for a connection request load balancing across SCAN listeners floating in the cluster.  If your DNS is set up to provide round-robin access to the IPs resolved by the SCAN entry, then run the “nslookup” command at least twice to see the round-robin algorithm work. The result should be that each time, the “nslookup” would return a set of three IPs in a different order.

Hope it helped !! 🙂