Single Client Access Name (SCAN) is a new Oracle Real Application Clusters (RAC) 11g Release 2 feature that provides a single name for clients to access Oracle Databases running in a cluster. Thebenefit is that the 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(s) 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.
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.
EZconnet sqlplus system/manager@krac-scan:1521/ORCL.INDIA.COM
JDBC connect jdbc:oracle:thin:@krac-scan:1521/ORCL.INDIA.COM
NETWORK 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. You must install Oracle Grid Infrastructure first in order to use Oracle RAC 11g Release 2. During the interview phase of the Oracle Grid Infrastructure installation, you will be prompted to provide a SCAN name. 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)
Define the SCAN in your corporate DNS (Domain Name Service)
If you choose Option 1, you must ask your network administrator to create a single name that resolves to 3 IP addresses using a round-robin algorithm. Three IP addresses are recommended considering load balancing and high availability requirements regardless of the number of servers in the cluster. 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 (for example: “krac-scan’ must be resolvable as opposed to “krac-scan.india.com”). The IPs must not be assigned to a network interface (on the cluster), since Oracle Clusterware will take care of it.
kracnode-scan 192.168.1.72
192.168.1.70
192.168.1.71
You can check the SCAN configuration in DNS using “nslookup”. 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 3 IPs in a different order.
First nslookup
[root@kracnode2 ~]# nslookup kracnode-scan
Server: 192.168.1.100
Address: 192.168.1.100#53
Name: kracnode-scan.india.com
Address: 192.168.1.72
Name: kracnode-scan.india.com
Address: 192.168.1.70
Name: kracnode-scan.india.com
Address: 192.168.1.71
Second nslookup
[root@kracnode2 ~]# nslookup kracnode-scan
Server: 192.168.1.100
Address: 192.168.1.100#53
Name: kracnode-scan.india.com
Address: 192.168.1.70
Name: kracnode-scan.india.com
Address: 192.168.1.71
Name: kracnode-scan.india.com
Address: 192.168.1.72
THE GRID NAMING SERVICE (GNS)
If you choose option 2, you only need to enter the SCAN during the interview. During the cluster configuration, three IP addresses will be acquired from a DHCP service (using GNS assumes you have a DHCP service available on your public network) to create the SCAN and name resolution for the SCAN will be provided by the GNS.
IF YOU DO NOT HAVE A DNS SERVER AVAILABLE AT INSTALLATION TIME
Oracle Universal Installer (OUI) enforces providing a SCAN resolution during the Oracle Grid Infrastructure installation, since the SCAN concept is an essential part during the creation of Oracle RAC 11g Release 2 databases in the cluster. All Oracle Database 11g Release 2 tools used to create a database (e.g. the Database Configuration Assistant (DBCA), or the Network Configuration Assistant (NetCA)) would assume its presence. Hence, OUI will not let you continue with the installation until you have provided a suitable SCAN resolution.
However, in order to overcome the installation requirement without setting up a DNS-based SCAN resolution, you can use a hosts-file based workaround. In this case, you would use a typical hosts-file entry to resolve the SCAN to only 1 IP address and one IP address only. It is not possible to simulate the round-robin resolution that the DNS server does using a local host file. The host file look-up the OS performs will only return the first IP address that matches the name. Neither will you be able to do so in one entry (one line in the hosts-file). Thus, you will create only 1 SCAN for the cluster. (Note that you will have to change the hosts-file on all nodes in the cluster for this purpose.)
This workaround might also be used when performing an upgrade from former (pre-Oracle Database 11g Release 2) releases. However, it is strongly recommended to enable the SCAN configuration as described under “Option 1” or “Option 2” above shortly after the upgrade or the initial installation. In order to make the cluster aware of the modified SCAN configuration, delete the entry in the hosts-file and then issue: "srvctl modify scan -n <scan_name>" as the root user on one node in the cluster. The scan_name provided can be the existing fully qualified name (or a new name), but should be resolved through DNS, having 3 IPs associated with it, as discussed. The remaining reconfiguration is then performed automatically.
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 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 + 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 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.
[oracle@kracnode1 ~]$ 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
[oracle@kracnode1 ~]$ srvctl config scan
SCAN name: kracnode-scan.india.com, Network: 1/192.168.1.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP: /192.168.1.70/192.168.1.70
SCAN VIP name: scan2, IP: /192.168.1.71/192.168.1.71
SCAN VIP name: scan3, IP: /192.168.1.72/192.168.1.72
[oracle@kracnode1 ~]$
DATABASE CONFIGURATION USING SCAN
For Oracle Database 11g Release 2, SCAN is an essential part of the 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). By default, a node listener is created on each node in the cluster during cluster configuration. With Oracle Grid Infrastructure 11g Release 2 the node listener run out of the Oracle Grid Infrastructure home and listen on the node-VIP using the specified port (default port is 1521).
Unlike in former database versions, it is not recommended to set your REMOTE_LISTENER parameter to a server side TNSNAMES alias that resolves the host to the SCAN (HOST=kracnode-scan for example) in the address list entry, but use the simplified “SCAN:port”
SQL> show parameter listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
listener_networks string
local_listener string (DESCRIPTION=(ADDRESS_LIST=(AD
DRESS=(PROTOCOL=TCP)(HOST=krac
node1-vip)(PORT=1521))))
remote_listener string kracnode-scan.india.com:1521
Note: if you are using the easy connect naming method, you may need to modify your SQLNET.ORA to ensure that EZCONNECT is in the list when specifying the order of the naming methods used for the client name resolution lookups (the Oracle 11g Release 2 default is NAMES.DIRECTORY_PATH=(tnsnames, ldap, ezconnect)).
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.
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.
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 ?
"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."
[oracle@kracnode1]$ srvctl STATUS SCAN_LISTENER
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node kracnode1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node kracnode2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node kracnode3
[oracle@kracnode1]$
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.
failure at end of installation (See NOTE 887471.1 for more details)
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?
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.
Sample TNS entry for SCAN
ORCL =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=kracnode-scan.india.COM)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ORCL.INDIA.COM))
)
Sample TNS Entry without SCAN
ORCL =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=kracnode1-vip.india.com)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=kracnode2-vip.india.com)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME=ORCL.INDIA.COM))
)
*****************************************************************************************************************************
Step by step DNS Configuration on Linux RHEL5/OEL5
Welcome to our page. In this page we are going to discuss about Domain Name Server(DNS) configuration. Later the same DNS configuration going to use Oracle 11g Release 2 Real Application Cluster (RAC) Installations.
Step 1 : Login as root and install below listed Bind RPM's.
rpm -Uvh bind-9.3.3-7.el5.i386.rpm \
bind-chroot-9.3.3-7.el5.i386.rpm \
bind-devel-9.3.3-7.el5.i386.rpm \
bind-libbind-devel-9.3.3-7.el5.i386.rpm \
bind-libs-9.3.3-7.el5.i386.rpm \
bind-sdb-9.3.3-7.el5.i386.rpm \
system-config-bind-4.0.3-2.el5.noarch.rpm \
bind-chroot-9.3.3-7.el5.i386.rpm \
bind-devel-9.3.3-7.el5.i386.rpm \
bind-libbind-devel-9.3.3-7.el5.i386.rpm \
bind-libs-9.3.3-7.el5.i386.rpm \
bind-sdb-9.3.3-7.el5.i386.rpm \
system-config-bind-4.0.3-2.el5.noarch.rpm \
caching-nameserver-9.3.3-7.el5.i386.rpm \
postgresql-libs-8.1.4-1.1.i386.rpm
Step 2: Verify the IP address for the DNS server. Use following command to check the IP address.
[root@dnc ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:7D:60:F3
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe7d:60f3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4919 (4.8 KiB) TX bytes:5628 (5.4 KiB)
Interrupt:67 Base address:0x2024
eth0 Link encap:Ethernet HWaddr 00:0C:29:7D:60:F3
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe7d:60f3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4919 (4.8 KiB) TX bytes:5628 (5.4 KiB)
Interrupt:67 Base address:0x2024
Step 3: There are four files we have to edit. Find the below easy steps to configure the DNS server.
1. Create a named.conf file using sample named.caching-nameserver.conf file.
[root@dnc ~]# cd /var/named/chroot/etc/
[root@dnc etc]# ls
localtime named.caching-nameserver.conf named.rfc1912.zones rndc.key
[root@dnc etc]#cp named.caching-nameserver.conf named.conf
2. Edit the named.conf file based on your configuration. For example.
options {
listen-on port 53 { 192.168.1.100; };
# listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
listen-on port 53 { 192.168.1.100; };
# listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// Those options should be used carefully because they disable port
// randomization
// query-source port 53;
// query-source-v6 port 53;
// randomization
// query-source port 53;
// query-source-v6 port 53;
allow-query { any; };
allow-query-cache { localhost; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view localhost_resolver {
match-clients { any; };
match-destinations { 192.168.1.100; };
recursion yes;
include "/etc/named.rfc1912.zones";
};
allow-query-cache { localhost; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view localhost_resolver {
match-clients { any; };
match-destinations { 192.168.1.100; };
recursion yes;
include "/etc/named.rfc1912.zones";
};
3. Edit named.rfc1912.zones file. Sample file given below.
zone "." IN {
type hint;
file "named.ca";
};
zone "india.com" IN {
type master;
file "forward.zone";
allow-update { none; };
};
type master;
file "forward.zone";
allow-update { none; };
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
type master;
file "localhost.zone";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "reverse.zone";
allow-update { none; };
};
..
4. Change the permission to the above two files.
chgrp named named.conf
5. Change the directory to below location
cd /var/named/chroot/var/named
cp localdomain.zone forward.zone
cp named.local reverse.zone
6. Modify the forward.zone file. example
$TTL 86400
@ IN SOA dnc.india.com. root.dnc.india.com. (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS dnc.india.com.
dnc IN A 192.168.1.100
7. Modify the reverse.zone file
$TTL 86400
@ IN SOA dnc.india.com. root.dnc.india.com. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS dnc.india.com.
100 IN PTR dnc.india.com.
8. Change the ownership for both the files.
chgrp named reverse.zone
chgrp named forward.zone
9. make an entry to both /etc/hosts and /etc/resolv.conf files. The samples are below.
cat /etc/hosts
192.168.1.100 dnc.india.com dnc
cat /etc/resolve.conf
search india.com
namedserver 192.168.1.100
10. Restart the named services using below statement.
service named restart
11. Verify the DNS server using below statements
[root@dnc named]# dig dnc.india.com
; «» DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 «» dnc.india.com
;; global options: printcmd
;; Got answer:
;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 1483
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; global options: printcmd
;; Got answer:
;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 1483
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dnc.india.com. IN A
;dnc.india.com. IN A
;; ANSWER SECTION:
dnc.india.com. 86400 IN A 192.168.1.100
dnc.india.com. 86400 IN A 192.168.1.100
;; AUTHORITY SECTION:
india.com. 86400 IN NS dnc.india.com.
india.com. 86400 IN NS dnc.india.com.
;; Query time: 1 msec
;; SERVER: 192.168.1.100#53(192.168.1.100)
;; WHEN: Mon Aug 27 23:54:49 2012
;; MSG SIZE rcvd: 61
;; SERVER: 192.168.1.100#53(192.168.1.100)
;; WHEN: Mon Aug 27 23:54:49 2012
;; MSG SIZE rcvd: 61
12. To check reverse the zone
[root@dnc named]# dig -x 192.168.1.100
; «» DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 «» -x 192.168.1.100
;; global options: printcmd
;; Got answer:
;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 55949
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; global options: printcmd
;; Got answer:
;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 55949
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;100.1.168.192.in-addr.arpa. IN PTR
;100.1.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
100.1.168.192.in-addr.arpa. 86400 IN PTR dnc-priv.india.com.
100.1.168.192.in-addr.arpa. 86400 IN PTR dnc.india.com.
100.1.168.192.in-addr.arpa. 86400 IN PTR dnc-priv.india.com.
100.1.168.192.in-addr.arpa. 86400 IN PTR dnc.india.com.
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 86400 IN NS dnc.india.com.
1.168.192.in-addr.arpa. 86400 IN NS dnc.india.com.
;; ADDITIONAL SECTION:
dnc.india.com. 86400 IN A 192.168.1.100
dnc.india.com. 86400 IN A 192.168.1.100
;; Query time: 1 msec
;; SERVER: 192.168.1.100#53(192.168.1.100)
;; WHEN: Mon Aug 27 23:57:27 2012
;; MSG SIZE rcvd: 124
;; SERVER: 192.168.1.100#53(192.168.1.100)
;; WHEN: Mon Aug 27 23:57:27 2012
;; MSG SIZE rcvd: 124
13. To verify DNS Server using nslookup
[root@dnc named]# nslookup dnc.india.com
Server: 192.168.1.100
Address: 192.168.1.100#53
Name: dnc.india.com
Address: 192.168.1.100
Address: 192.168.1.100
DNS server working fine now. Finally we got success.
14. For Oracle 11gR2 RAC Installation adding node Information in/var/named/chroot/var/named/forward.zone file on DNS server.
14. For Oracle 11gR2 RAC Installation adding node Information in/var/named/chroot/var/named/forward.zone file on DNS server.
$TTL 86400
@ IN SOA dnc.india.com. root.dnc.india.com. (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS dnc.india.com.
dnc IN A 192.168.1.100
kracnode1 IN A 192.168.1.50
kracnode2 IN A 192.168.1.51
kracnode1-vip IN A 192.168.1.60
kracnode2-vip IN A 192.168.1.61
kracnode-scan IN A 192.168.1.70
kracnode-scan IN A 192.168.1.71
kracnode-scan IN A 192.168.1.72
15. Restart named service as a root user.
[root@dnc named]# service named restart
Stopping named: [ OK ]
Starting named: [ OK ]
16. Verify the SCAN names using nslookup.
[root@dnc named]# nslookup kracnode-scan
Server: 192.168.1.100
Address: 192.168.1.100#53
Name: kracnode-scan.india.com
Address: 192.168.1.72
Name: kracnode-scan.india.com
Address: 192.168.1.70
Name: kracnode-scan.india.com
Address: 192.168.1.71
17. Add below files in /etc/resolv.conf file on all the nodes.
search india.com
nameserver 192.168.1.100
[oracle@krac1 ]# cat /etc/resolv.conf
search india.com
nameserver 192.168.1.100
[root@krac1 bin]# nslookup kracnode-scan
Server: 192.168.1.100
Address: 192.168.1.100#53
Name: kracnode-scan.india.com
Address: 192.168.1.71
Name: kracnode-scan.india.com
Address: 192.168.1.72
Name: kracnode-scan.india.com
Address: 192.168.1.70
No comments:
Post a Comment