Database Reference
In-Depth Information
Second Network
In 11gR2, you can configure second network for public VIPs only. However, the second network cannot be
configured for cluster interconnect or SCAN network. In version 12c, the second network is supported for public,
VIP, and SCAN IP addresses. Second network is useful if there are multiple subnets configured for public network
traffic to the database.
The first step in adding second network resources is to add a network resource. The following command uses -k 2,
indicating that this is a second network, and lists the subnet as 10.5.12.0 on aggr1 and aggr2 devices.
$ srvctl add network -k 2 -S 10.5.12.0/255.255.254.0/aggr1:aggr2
Next, the VIP on that network is added using the following srvctl commands. For all commands, -k 2 indicates
that this VIP is for second network. A listener listening on second network port 1521 is also added using the add
listener command.
$ srvctl add vip -n node1 -k 2 -A 10.5.12.99/255.255.254.0/aggr1:aggr2
$ srvctl add vip -n node2 -k 2 -A 10.5.12.100/255.255.254.0/aggr1:aggr2
$ srvctl add listener -l listener2 -p 1521 -k 2
The next command modifies a listener_networks parameter in the database. Database PMON or LREG process
registers with the listener using this configuration. Note that for the first network, SCAN listener is specified as
remote_listener, but for the second network a VIP listener in remote node is specified.
alter system set LISTENER_NETWORKS='((NAME=network1)(LOCAL_LISTENER=listener_net1)(REMOTE_LISTENER=r
acscan:1521))','((NAME=network2)(LOCAL_LISTENER=listener_net2) (REMOTE_LISTENER=remote_net2))';
In 11gR2, while the listener_networks can be used for automatic service registration with both local VIP listener
and SCAN listener, it is not possible to use SCAN listener to redirect the connection for the second network. So, the
second network cannot be used in conjunction with SCAN listener as of 11gR2. Version 12c allows SCAN listeners in
the second network with a seamless network management of packets staying in the same subnet. Refer to Chapter 3
for exact commands to create a SCAN listener in the second network.
Further, listeners specified in the listener_networks parameter should not be specified in local_listener or
remote_listener parameter, since that will lead to cross-registration between two networks.
Summary
The network is a critical piece of RAC infrastructure. Understanding network architecture, Clusterware
implementation of the network, and the performance statistics of the network is of paramount importance when
designing a RAC infrastructure or debugging RAC performance issues.
Pay close attention to the kernel parameters, subnet masks, network interface configuration, etc., while
configuring clusters for RAC installation. It is much easier to resolve OS errors before configuring RAC. After the
RAC configuration, OS level change requires further considerations.
If you have errors in the database due to lost packets or performance issues indicating network issues, then you
should review network performance metrics using OS tools to identify any network configuration or performance
issues. We discussed various tools such as ping, netstat, traceroute, etc., which are essential to identify the root cause
of a performance issue.
