Podczas próby uruchomienia drugiej instancji w dwuwęzłowym klastrze RAC druga instancja nie zostanie uruchomiona. Jeśli instancja w węźle 1 jest uruchomiona, instancja w węźle 2 nie zostanie uruchomiona. Jeśli instancja w węźle 2 jest uruchomiona, instancja w węźle 1 nie zostanie uruchomiona. Dziennik alertów zawiera następujące informacje:
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
Niestety, plik śledzenia LMON zawiera tylko te same komunikaty o błędach, więc nie ma tam nic do zrobienia.
Ten błąd występuje z powodu błędnej konfiguracji połączenia międzysieciowego klastra. Jeśli spojrzysz na OCR, aby zobaczyć połączenie klastra, możesz zobaczyć, że urządzenie sieciowe to eth4.1338:
[oracle@myhost bin]$ oifcfg getif -global
eth2 192.168.33.0 global public
eth4.1338 10.0.0.0 global cluster_interconnect
W jednym węźle urządzenie eth4 jest poprawne. Jednak na drugim węźle urządzenie to eth5.1338, a OCR jest współdzielony między węzłami. OCR oczekuje, że urządzenie będzie eth4.1338. Oba serwery wymagają połączenia klastra, aby znajdowało się na tym samym urządzeniu sieciowym. Konfiguracja sieciowa serwera została zmieniona tak, że oba węzły zostały skonfigurowane na urządzeniu eth5.1338. Gdy serwery zostały skonfigurowane identycznie, zmieniliśmy konfigurację OCR:
[oracle@myhost bin]$ ./oifcfg setif -global eth5.1338/10.0.0.0:cluster_interconnect
Patrząc na konfigurację, widzimy, że zarówno eth4, jak i eth5 są nadal w 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
Więc usuwamy urządzenie eth4:
[oracle@myhost bin]$ ./oifcfg delif -global eth4.1338/10.0.0.0
Mamy teraz rekonfigurację OCR. Zrestartowaliśmy CRS i obie instancje pojawiły się na obu węzłach!
Był to jeden z tych błędów, w których komunikaty o błędach tak naprawdę nie wskazywały na pierwotną przyczynę problemu. Zamiast tego musiałem grzebać w obszarach, które moim zdaniem były najbardziej prawdopodobnymi winowajcami, kiedy raczej ślepo odkryłem różnice w konfiguracji.
