Ich habe eine Testdatenbank, die ein 2-Knoten-RAC-System ist. Ich arbeite auf das Ziel hin, die Produktionsdatenbank in etwa einem Monat auf Oracle 12.1.0.2 zu bringen. Dies bedeutet natürlich, dass ich die Grid-Infrastruktur vor dem db-Upgrade aktualisieren muss. Ich habe GI auf meinem Standby-Cluster und auch auf meiner Testdatenbank aktualisiert. Das primäre GI-Upgrade ist für heute Abend geplant.
Seit ich vor ein paar Wochen GI in Test aktualisiert habe, erhalte ich Warnungen von EM12c ähnlich der folgenden:
Host=host01
Zieltyp=Cluster
Zielname=Test-Scan
Categories=Unternehmen
Message=Der Server steht unter erhöhtem Speicherdruck und die Dienste auf allen Instanzen auf diesem Server werden gestoppt
Severity=Warnung
Zeitpunkt des Ereignisberichts =29. Juli 2015 13:05:13 Uhr CDT
Betriebssystem=Linux
Platform=x86_64
Ereignistyp=Metrikwarnung
Ereignisname=wlm_event:wlm_qosm_mpa_risk_state
Metrikgruppe=QoS-Ereignisse
Metric=Memory Pressure Analysis Risk State
Metrikwert=ROT
Einige der Benachrichtigungsdetails wurden der Kürze halber entfernt.
Also wo kommt das her? Warum bedeutet es mir?
Dieser Fehler kommt von Oracles Quality of Service (QoS) in der Grid-Infrastruktur. Es stützt sich auf Cluster Health Monitor (CHM)-Informationen. Genauer gesagt kommt diese Warnung von Memory Guard. Einige Informationen zu Memory Guard finden Sie in diesem PDF, insbesondere am Ende der zweiten Seite.
Memory Guard versucht, mich vor mir selbst zu retten, und wie wir sehen werden, macht es einen schlechten Job. Die Idee ist, dass Memory Guard alle Dienste auf diesem Knoten außer Betrieb nehmen wird, wenn der Server Speicherdruck hat. Das Zulassen von mehr Verbindungen würde noch mehr Speicher verbrauchen und könnte die Situation verschlimmern. Neue Verbindungsanforderungen müssen an einen anderen Knoten im Cluster gehen, auf dem dieser Dienst ausgeführt wird. Genau das sagt mir der Message-Wert in der Warnung.
Gemäß diesem EM 12c-Dokument, Abschnitt 4.3.2, Memory Pressure Analysis Risk State, soll der Warnungstext den Servernamen enthalten. Der obige Meldungstext sagt mir jedoch nicht, welcher Server das Problem hat. Glücklicherweise ist es nur ein RAC-Cluster mit 2 Knoten, sodass ich nicht zu viele untersuchen muss.
Wenn ich mir die CPU-Auslastung ansehe, ist alles in Ordnung. Die Swap-Nutzung ist auf beiden Knoten praktisch Null. Der freie Speicher beträgt auf beiden Knoten mehr als 25 %. Neugierig … warum überhaupt die Warnung?
Jedes Mal, wenn ich diese Benachrichtigung erhalte, kann ich eine weitere E-Mail erhalten, die besagt, dass der Zustand innerhalb weniger Minuten behoben ist. Das Problem ist also nur von kurzer Dauer. Aber die Warnungen kommen immer wieder.
Nach einigen Untersuchungen stellt sich heraus, dass Oracle in Grid Infrastructure 12.1.0.2 eine Änderung an Memory Guard vorgenommen hat. In früheren Versionen kümmerte sich Memory Guard nur um richtlinienverwaltete Datenbanken. In GI 12.1.0.2 begann Memory Guard, sich auch um vom Administrator verwaltete Datenbanken zu kümmern. Und meine RAC-Datenbanken werden normalerweise vom Administrator verwaltet, was einer der Gründe ist, warum ich das jetzt sehe.
Um das Problem weiter zu verschärfen, hat GI 12.1.0.2 anscheinend den Fehler 1582630 bekannt, bei dem die Menge an freiem Speicher falsch berechnet wird. Hinweis 1929994.1 listet eine Problemumgehung auf und es gibt auch einen Patch. Ich habe die Problemumgehung angewendet und sie hat mein Problem gelöst. Ich werde den Patch auf Test anwenden lassen, bevor ich in nicht allzu ferner Zukunft mit der Produktion fortfahre.
Glücklicherweise habe ich dies vor meinem Produktions-GI-Upgrade später heute Abend entdeckt. Andernfalls hätte ich verärgerte Endbenutzer gehabt, die möglicherweise Probleme beim Herstellen einer Verbindung zur Datenbank hatten. Dies ist nur ein weiteres Beispiel dafür, warum ich über eine gute Testplattform verfüge, mit der ich Probleme erkennen und lösen kann, bevor die Änderung in der Produktion vorgenommen wird.
