2ノードRACクラスターで2番目のインスタンスを開始しようとすると、2番目のインスタンスは開始されません。 node1のインスタンスが実行されている場合、node2のインスタンスは起動しません。 node2のインスタンスが実行されている場合、node1のインスタンスは起動しません。アラートログには次の情報が表示されます：
Error: KGXGN polling error (15)
Errors in file /u01/app/oracle/diag/rdbms/bsp/bsp1/trace/bsp1_lmon_9151.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON (ospid: 9151): terminating the instance due to error 29702
残念ながら、LMONトレースファイルは同じエラーメッセージしか表示しないため、そこには何も表示されません。
このエラーは、クラスター相互接続の構成ミスが原因で発生しています。 OCRを見てクラスターの相互接続を確認すると、NICデバイスがeth4.1338であることがわかります。
[oracle@myhost bin]$ oifcfg getif -global
eth2 192.168.33.0 global public
eth4.1338 10.0.0.0 global cluster_interconnect
1つのノードでは、デバイスeth4が正しいです。ただし、2番目のノードでは、デバイスはeth5.1338であり、OCRはノード間で共有されます。 OCRは、デバイスがeth4.1338であることを期待しています。両方のサーバーで、クラスター相互接続が同じネットワークデバイス上にある必要があります。サーバーのネットワーク構成が変更され、両方のノードがeth5.1338デバイスで構成されました。サーバーが同じように構成されたら、OCR構成を再定義しました：
[oracle@myhost bin]$ ./oifcfg setif -global eth5.1338/10.0.0.0:cluster_interconnect
構成を見ると、eth4とeth5の両方がまだOCRにあることがわかります：
[oracle@myhost bin]$ ./oifcfg getif -global
eth2 192.168.33.0 global public
eth4.1338 10.0.0.0 global cluster_interconnect
eth5.1338 10.0.0.0 global cluster_interconnect
そこで、eth4デバイスを削除します：
[oracle@myhost bin]$ ./oifcfg delif -global eth4.1338/10.0.0.0
これで、OCRが再構成されました。 CRSを再起動すると、両方のインスタンスが両方のノードで起動しました！
これは、エラーメッセージが実際には問題の根本原因を示していないエラーの1つでした。代わりに、構成の違いをやみくもに発見したときに、犯人である可能性が最も高いと感じた領域を調べなければなりませんでした。