Sunday, January 23, 2011

Oracle 11gR2 New Feature: SCAN (Single Client Access Name)

Single Client Access Name (SCAN) is a new Oracle Real Application Clusters (RAC) 11g R2 feature thatprovides a single name for clients to access Oracle Databases running in a cluster.

The benefits of SCAN are
  • Client’s connect information does not need to change if you add or remove nodes in the cluster.
  • Having a single name to access the cluster allows clients to use the EZConnect client and the simple JDBC thin URL to access any database running in the cluster, independently of which server in the cluster the database is active.
  • SCAN provides load balancing and failover for client connections to the database. The SCAN works as a cluster alias for databases in the cluster.
Example for EZConnect and Thin JDBC Connect Strings

EZconnet sqlplus system/belMan@saab1-scan:1521/oltp
JDBC connect jdbc:oracle:thin:@saab1-scan:1521/oltp

REQUIREMENTS FOR USING SCAN

The SCAN is configured during the installation of Oracle Grid Infrastructure that is distributed with Oracle Database 11g Release2. Oracle Grid Infrastructure is a single Oracle Home that contains Oracle Clusterware and Oracle Automatic Storage Management.

There are 2 options for defining the SCAN:
1. Define the SCAN in your corporate DNS (Domain Name Service)
2. Use the Grid Naming Service (GNS)

USING OPTION 1
-DEFINE THE SCAN IN YOUR Site DNS In This method you must ask your network administrator to create a single
name that resolves to 3 IP addresses using a round-robin algorithm, which are recommended for load balancing and high availability

Note -The IP addresses must be on the same subnet as your public network in the cluster. -The name must be 15 characters or less in length, not including the domain, and must be resolvable without the domain suffix -The IPs must not be assigned to a network interface (on the cluster)
Example for DNS entry for SCAN Saab1-scan.
IN A 192.168.1.176
IN A 192.168.1.177
IN A 192.168.1.178

Use nslookup to check the SCAN configuration in DNS The Output Should be something like this

First nslookup:

[adfprd1] nslookup saab1-scan Server: 192.168.170
Address: 192.168.170#60
Non-authoritative answer: Name: saab1-scan Address:
192.168.1.176 Name: saab1-scan Address: 192.168.1.177
Name: saab1-scan Address: 192.168.1.178

Second nslookup:

[adfprd2] nslookup saab1-scan Server: 192.168.170
Address: 192.168.170#60
Non-authoritative answer: Name: saab1-scan Address:
192.168.1.176 Name: saab1-scan Address: 192.168.1.177
Name: saab1-scan Address: 192.168.1.178

If your DNS server does not return a set of 3 IPs as shown in the table or does not round-robin, ask your network administrator to enable such a setup. DNS using a round-robin algorithm on its own does not ensure failover of connections.

USING OPTION 2
- THE GRID NAMING SERVICE (GNS) In This method, you only need to enter the SCAN during the interview. During the cluster configuration, 3 IP addresses will be acquired from a DHCP service and DNS to create the SCAN and name resolution for the SCAN will be provided by the GNS1.

DHCP configuration Files
/etc/dhcpd.conf
DNS for GNS
/etc/named.conf
/var/named/the-playground.zone
/var/named/the-playground.reverse
/etc/resolv.conf /etc/nsswitch.conf

SCAN CONFIGURATION IN THE CLUSTER During cluster configuration, several resources are created in the cluster for SCAN For each of the 3 IP addresses that the SCAN resolves SCAN VIP resource SCAN Listener This means, each pair of resources (SCAN VIP + Listener) will be started on a different server in the cluster, assuming the cluster consists of three or more nodes. If the node where a SCAN VIP is running fails, the SCAN VIP and its associated listener will failover 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. If a node becomes available in the cluster again, the formerly mentioned dispersion will take effect and relocate one set accordingly.

Example for SCAN Configuration

Running following command on Node2-adfprd2
$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node adfprd1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node adfprd2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node adfprd2
$ ps -aef |grep -i SCAN
oracle 9545 1 0 Jul13 ? 11:06:01 /d01/apps/oracle_crs/11.2/bin/tnslsnr
LISTENER_SCAN2 -inherit oracle 9545 1 0 Jul13 ? 11:06:01 /d01/apps/oracle_crs/11.2/bin/tnslsnr
LISTENER_SCAN3 -inheritoracle 9976 2214 0 11:10 pts/3 00:00:00 grep -i crs
$ srvctl config scan_listener 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

$ srvctl config scan
SCAN name: saab1-scan, Network: 1/192.168.1.0/255.255.255.0/
SCAN VIP name: scan1, IP: /saab1-scan/192.168.1.176
SCAN VIP name: scan2, IP: /saab1-scan/192.168.1.177
SCAN VIP name: scan3, IP: /saab1-scan/192.168.1.178

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

TNSNAMES.ora Without SCAN:

prod1 =
(DESCRIPTION =
(ADDRESS_LIST = (LOAD_BALANCE = ON) (FAILOVER = ON)
(ADDRESS =
(PROTOCOL = tcp) (HOST = adfprd1-vip)(PORT = 1521))
(ADDRESS =
(PROTOCOL = tcp)(HOST = adfprd2-vip)(PORT =1521)) )
(CONNECT_DATA = (SERVICE_NAME = saab1) ) )

TNSNAMES.ora enter With SCAN:

Prod1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)(HOST = saab1-scan)
(PORT = 1521)) ) (CONNECT_DATA =
(SERVICE_NAME = saab1) ) )

VERSION AND BACKWARD COMPATIBILITY

The successful use of SCAN to connect to an Oracle RAC database in the cluster depends on the ability of the client to understand and use the SCAN as well as on the correct configuration of the REMOTE_LISTENER parameter setting in the database.

If the version of the Oracle Client connecting to the database as well as the Oracle Database version used are both Oracle Database 11g Release 2 and the default configuration is used as described in this paper, no changes to the system are typically required, if the Oracle Client version and the version of the Oracle Database that this client is connecting to are both pre-11g Release 2 version The disadvantage of this configuration is that SCAN would not be used and hence the clients are still exposed to changes every time the cluster changes in the
backend. Similarly, If an Oracle Database 11g Release 2 is used, but the clients remain on a former version. The solution is to change the Oracle client and / or Oracle Database REMOTE_LISTENER settings accordingly.

The following table shows the Matrix for Version and Backward Compatibility
Oracle Client Version Oracle Database Version Comment
Oracle Database 11g Release 2 Oracle Database 11g Release 2 No change required.
Oracle Database 11g Release 2 Pre- Oracle Database 11g Release 2 Add the SCAN VIPs as hosts to the REMOTE_LISTENER parameter.












USING SCAN IN A MAXIMUM AVAILABILITY ARCHITECTURE ENVIRONMENT
If you have implemented a Maximum Availability Architecture (MAA) environment, in which you use Oracle RAC for both your primary and standby database (in both, your primary and standby site), which are synchronized using Oracle Data Guard, using SCAN provides a
simplified TNSNAMES configuration that a client can use to connect to the database independently of whether the primary or standby database is the currently active (primary) database.

In order to use this simplified configuration, Oracle Database 11g Release 2 introduces two new SQL*Net parameters

1-CONNECT_TIMEOUT, This parameter overrides SQLNET.OUTBOUT_CONNECT_TIMEOUT in the SQLNET.ORA

2-RETRY_COUNT and it specifies the number of times an ADDRESS_LIST is traversed before the connection attempt is terminated

Example for TNSNAMES.ORA entry in Maximum Availability Architecture

saabstndby =
(DESCRIPTION= (CONNECT_TIMEOUT=10)(RETRY_COUNT=3) (ADDRESS_LIST= (LOAD_BALANCE=on)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=adfprd1-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME= stanbydb))

USING SCAN WITH ORACLE CONNECTION MANAGER
If you use Oracle Connection Manager (CMAN) with your Oracle RAC Database, the REMOTE_LISTE ER parameter for the Oracle RAC instances should include the CMAN server so that the CMAN server will receive load balancing related information and can therefore
load balance connections across the available instances Example for Server side TNSNAMES.ora example entry when using CMAN

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


Reference: wiki.oracle.com

No comments:

Post a Comment