Using Serviceguard Extension for RAC, 7th Edition, September 2008

DEPENDENCY_NAME CI-PACKAGE
DEPENDENCY_CONDITION CI-PACKAGE=UP
DEPENDENCY_LOCATION SAME_NODE
Oracle Cluster Interconnect Subnet Package: Package to monitor the CSS-HB subnet
PACKAGE_NAME CI-PACKAGE
PACKAGE_TYPE MULTI_NODE
LOCAL_LAN_FAILOVER_ALLOWED YES
NODE_FAIL_FAST_ENABLED YES
CLUSTER_INTERCONNECT_SUBNET 192.168.1.0
NOTE: For information on guidelines to change certain Oracle Clusterware and Serviceguard
cluster configuration parameters, see “Guidelines for Changing Cluster Parameters” (page 41)
Alternate Configuration - Multiple RAC Databases
When there are multiple independent RAC databases on the same cluster and if there is insufficient
bandwidth over a single network, a separate network can be used for different database
interconnect traffic. This will avoid RAC-IC traffic of one database from interfering with that of
another.
Figure 2-3 RAC/RAC-IC Traffic Separation – Multiple Database Configuration
As shown in Figure 2-3, each primary and standby pair protects against a single failure. If the
subnet with SG-HB (lan1/lan2) fails, Serviceguard will resolve the subnet failure with a
Serviceguard cluster reconfiguration. If the 192.168.2.0 subnet (lan3 and lan4) fails, Oracle instance
membership recovery (IMR) will resolve the interconnect failure subnet, unless Serviceguard
subnet monitoring is used. Oracle will wait for IMR time interval prior to resolving the subnet
failure. In SGeRAC configurations, default value of IMR time interval may be as high as seventeen
minutes.
CLUSTER_INTERCONNECT_SUBNET can be configured for RAC instance MNP to monitor the
RAC-IC subnet that is different from CSS-HB subnet. The parameter file (SPFILE or PFILE)
for RAC instances must have cluster_interconnects parameter defined, to hold IP address
in the appropriate subnet if the RAC Instances use a RAC-IC network different from CSS-HB
network. No special subnet monitoring is needed for CSS-HB Subnet because Serviceguard
monitors the subnet (heartbeat) and will handle failures of the subnet.
The database instances that use 192.168.2.0 must have cluster_interconnects defined in
their SPFILE or PFILE as follows:
orcl1.cluster_interconnects=’192.168.2.1’
orcl2.cluster_interconnects=’192.168.2.2’
Cluster Communication Network Monitoring 39