Database Reference
In-Depth Information
A typical situation under these circumstances would be when one or both of the instances lose communication
with the other instance and waits until it receives a failure signal. The failure of the cluster interconnect could cause
a communication failure between the two nodes. When the heartbeat mechanism between the two nodes is not
successful, the OCW triggered by the heartbeat timeout parameter signals a node failure. However, because there was
no physical failure of the instance and/or node, the Global Enqueue Service Monitor ( LMON ) process is unable to write
to the disk regarding the status of the other instance.
Although there is no physical failure of the instance and/or node, every instance would wait to receive a
communication from the other instance either that it's up and alive and communication could continue or that
the other instance is down and is not communicating. If after a certain time period there is no response, one of the
instances that is currently up will try to force shutdown of the instance that is not responding.
When the communication between the instances fail, the instances will slow down and hang eventually, with
severe impact on performance. This is due to the fact that the Oracle kernel is repeatedly trying to shut down other
unreachable instances to perform recovery. When this happens, it calls for a manual intervention (in extremely rare
cases) where the DBA would be required to shutdown one of the instances to allow business to continue.
To avoid this single point of failure, business organizations should configure dual or multiple interconnects.
Methods of Implementing Redundant Interconnects
Oracle supports implementing redundant interconnects using one of the following methods.
CLUSTER_INTERCONNECT
One method of implementing this feature is to use the CLUSTER_INTERCONNECT parameter. By listing the IP addresses,
Oracle is made aware of the additional interconnects and Oracle will use them for communication.
ALTER SYSTEM SET CLUSTER_INTERCONNECT= '192.30.0.96: 192.30.0.100: 192.30.0.98'
scope=SPFILE SID='SSKY_1';
Script: MVRACPDnTap_verifyic.sql
Impl
ADDR Indx Public Type Name IP Address
---------------- ------ --------- ----- ------- -------------
00002B35D99D89A0 0 N CI eth23 192.30.0.96
00002B35D99D89A0 1 N CI eth21 192.30.0.100
00002B35D99D89A0 2 N CI eth22 192.30.0.98
Inst Name IP Address IS_PUBLIC Source
---- ------ ------------ --------- -------------------------------
1 eth21 192.30.0.100 NO cluster_interconnects parameter
1 eth22 192.30.0.98 NO cluster_interconnects parameter
1 eth23 192.30.0.96 NO cluster_interconnects parameter
In this configuration, Instance 1 has three interconnects configured. The drawback to using the
CLUSTER_INTERCONNECT parameter is that some of high availability (HA) features will be lost.
oracle does not recommend use of this parameter. this parameter does not guarantee ha on all platforms and
in all releases of oracle.
Note
 
Search WWH ::




Custom Search