sql >> Database >  >> RDS >> Oracle

Geheugendruk Analyse Risicostatus

Ik heb een testdatabase die een RAC-systeem met 2 knooppunten is. Ik werk aan het doel om de productiedatabase in ongeveer een maand tijd naar Oracle 12.1.0.2 te krijgen. Dit betekent natuurlijk dat ik de Grid Infrastructure moet upgraden voorafgaand aan de db-upgrade. Ik heb GI op mijn reservecluster en ook op mijn Testgegevensbestand geüpgraded. De primaire GI-upgrade is gepland voor vanavond.

Sinds ik een paar weken geleden GI in Test heb geüpgraded, krijg ik meldingen van EM12c die vergelijkbaar zijn met het volgende:

Host=host01
Doeltype=Cluster
Doelnaam=test-scan
Categorieën=Zakelijk
Message=Server staat onder verhoogde geheugendruk en services op alle instanties op deze server worden gestopt
Severity=Waarschuwing
Event gerapporteerde tijd=29 juli 2015 13:05:13 CDT
Besturingssysteem=Linux
Platform=x86_64
Gebeurtenistype=Metrische waarschuwing
Naam evenement=wlm_event:wlm_qosm_mpa_risk_state
Metric Group=QoS-gebeurtenissen
Metric=Risicostatus voor analyse van geheugendruk
Metrische waarde=ROOD

Enkele meldingsdetails zijn verwijderd voor de beknoptheid.

Dus waar komt dit vandaan? Waarom betekent het voor mij?

Deze fout komt van Oracle's Quality of Service (QoS) in Grid Infrastructure. Het is gebaseerd op Cluster Health Monitor (CHM) informatie. Meer specifiek komt deze waarschuwing van Memory Guard. Voor wat informatie over Memory Guard, zie deze PDF, met name het einde van de tweede pagina.

Memory Guard probeert me van mezelf te redden, en zoals we zullen zien, doet het dat slecht. Het idee is dat wanneer de server geheugendruk heeft, Memory Guard alle services op dat knooppunt buiten dienst zal stellen. Het toestaan ​​van meer verbindingen zou nog meer geheugen verbruiken en de situatie erger maken. Nieuwe verbindingsaanvragen moeten naar een ander knoop punt gaan in het cluster waarop die service wordt uitgevoerd. Dit is precies wat de berichtwaarde in de waarschuwing me vertelt.

Volgens dit EM 12c-document, paragraaf 4.3.2, Geheugendrukanalyse Risicostatus, wordt verondersteld dat de waarschuwingstekst de servernaam bevat. Maar de berichttekst hierboven vertelt me ​​niet welke server het probleem heeft. Gelukkig voor mij is het slechts een RAC-cluster met 2 knooppunten, dus ik heb er niet te veel om te onderzoeken.

Als ik naar het CPU-gebruik kijk, is alles in orde. Het swapgebruik is op beide knooppunten praktisch nul. Vrij geheugen is meer dan 25% op beide knooppunten. Nieuwsgierig...waarom de waarschuwing in de eerste plaats?

Telkens wanneer ik deze waarschuwing ontvang, kan ik een andere e-mail sturen waarin staat dat de toestand binnen een paar minuten is verholpen. Het probleem is dus van korte duur. Toch blijven de waarschuwingen komen.

Na enig onderzoek blijkt dat Oracle een wijziging heeft aangebracht in Memory Guard in Grid Infrastructure 12.1.0.2. In eerdere versies zorgde Memory Guard alleen voor door beleid beheerde databases. In GI 12.1.0.2 begon Memory Guard ook met het beheren van door de beheerder beheerde databases. En mijn RAC-databases worden doorgaans door de beheerder beheerd, wat een reden is waarom ik dit nu zie.

Om het probleem nog verder te verergeren, heeft GI 12.1.0.2 blijkbaar bug 1582630 gekend, waarbij de hoeveelheid vrij geheugen onjuist werd berekend. Note 1929994.1 somt een tijdelijke oplossing op en er is ook een patch. Ik heb de tijdelijke oplossing toegepast en het loste mijn probleem op. Ik zorg ervoor dat de patch op Test wordt toegepast voordat ik in de niet al te verre toekomst tot productie overga.

Gelukkig ontdekte ik dit voor mijn productie-GI-upgrade later vanavond. Anders zou ik eindgebruikers van streek hebben gemaakt die mogelijk problemen hebben ondervonden bij het verbinden met de database. Dit is nog maar een voorbeeld van waarom ik een goed testplatform heb waarmee ik de problemen kan ontdekken en oplossen voordat de wijziging in productie wordt doorgevoerd.


  1. Meest populaire databasebeheersystemen ter wereld

  2. Waarom geeft mysqli de foutmelding 'Commands out of sync'?

  3. MariaDB JSON_TABLE() uitgelegd

  4. Het equivalent van de SQLServer-functie SCOPE_IDENTITY() in mySQL?