sql >> Database >  >> RDS >> Oracle

KGXGN polling-fout (15)

Wanneer u probeert het tweede exemplaar te starten in een RAC-cluster met twee knooppunten, wordt het tweede exemplaar niet gestart. Als de instance op node1 actief is, zal de instance op node2 niet starten. Als de instance op node2 actief is, zal de instance op node1 niet starten. Het waarschuwingslogboek toont het volgende:

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

Helaas geeft het LMON-traceringsbestand alleen dezelfde foutmeldingen, dus daar valt niets aan te doen.

Deze fout treedt op vanwege een verkeerde configuratie voor de cluster-interconnect. Als je naar de OCR kijkt om de cluster-interconnect te zien, kun je zien dat het NIC-apparaat eth4.1338 is:

[oracle@myhost bin]$ oifcfg getif -global
eth2 192.168.33.0 global public
eth4.1338 10.0.0.0 global cluster_interconnect

Op één knooppunt is het apparaat eth4 correct. Op het tweede knooppunt is het apparaat echter eth5.1338 en wordt de OCR gedeeld tussen de knooppunten. De OCR verwacht dat het apparaat eth4.1338 is. Beide servers hebben de clusterinterconnect nodig om zich op hetzelfde netwerkapparaat te bevinden. De netwerkconfiguratie van de server is gewijzigd zodat beide nodes zijn geconfigureerd op het eth5.1338-apparaat. Nadat de servers identiek waren geconfigureerd, hebben we de OCR-configuratie opnieuw gedefinieerd:

[oracle@myhost bin]$ ./oifcfg setif -global eth5.1338/10.0.0.0:cluster_interconnect

Als we naar de configuratie kijken, kunnen we zien dat zowel eth4 als eth5 nog steeds in OCR zijn:

[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

Dus we verwijderen het eth4-apparaat:

[oracle@myhost bin]$ ./oifcfg delif -global eth4.1338/10.0.0.0

We hebben nu de OCR opnieuw geconfigureerd. We hebben CRS opnieuw opgestart en beide instanties kwamen op beide knooppunten!

Dit was een van die fouten waarbij de foutmeldingen niet echt op een oorzaak van het probleem wezen. In plaats daarvan moest ik rondneuzen in de gebieden waarvan ik dacht dat ze de meest waarschijnlijke boosdoeners waren toen ik nogal blindelings de configuratieverschillen ontdekte.


  1. Standaardwaarden van parameters parseren met PowerShell - Deel 2

  2. SQL Server recursieve query

  3. Hoe kan ik de oorzaak van de Hibernate-uitzondering verhelpen. IllegalArgumentException is opgetreden tijdens het aanroepen van setter?

  4. VMware CPU Hot Plug vNUMA-effecten op SQL Server