Mam testową bazę danych, która jest 2-węzłowym systemem RAC. Pracuję nad osiągnięciem celu, jakim jest przeniesienie produkcyjnej bazy danych do Oracle 12.1.0.2 za około miesiąc. To oczywiście oznacza, że muszę zaktualizować Grid Infrastructure przed aktualizacją bazy danych. Zaktualizowałem GI w moim klastrze rezerwowym oraz w mojej testowej bazie danych. Główna aktualizacja GI jest zaplanowana na ten wieczór.
Odkąd ulepszyłem GI w Test kilka tygodni temu, otrzymuję alerty z EM12c podobne do następujących:
Host=host01
Typ docelowy=Klaster
Nazwa docelowa=skanowanie testowe
Kategorie=Biznes
Message=Serwer jest pod zwiększonym obciążeniem pamięci i usługi na wszystkich instancjach na tym serwerze zostaną zatrzymane
Istotność=Ostrzeżenie
Czas zgłoszenia zdarzenia=29 lipca 2015 13:05:13 CDT
System operacyjny=Linux
Platforma=x86_64
Event Type=Alert danych
Nazwa zdarzenia=wlm_event:wlm_qosm_mpa_risk_state
Metric Group=Zdarzenia QoS
Metric=Stan ryzyka analizy ciśnienia pamięci
Wartość wskaźnika=CZERWONY
Niektóre szczegóły alertu zostały usunięte ze względu na zwięzłość.
Więc skąd to się bierze? Dlaczego to dla mnie znaczy?
Ten błąd pochodzi z Oracle Quality of Service (QoS) w infrastrukturze sieciowej. Opiera się na informacjach z Monitora kondycji klastra (CHM). Dokładniej, ten alert pochodzi od Straży Pamięci. Więcej informacji na temat Straży pamięci znajdziesz w tym pliku PDF, a konkretnie na końcu drugiej strony.
Strażnik Pamięci próbuje mnie uratować przed samym sobą i jak zobaczymy, kiepsko sobie radzi. Chodzi o to, że gdy serwer ma obciążoną pamięć, Memory Guard wyłączy wszystkie usługi w tym węźle. Zezwolenie na większą liczbę połączeń zużyłoby jeszcze więcej pamięci i mogłoby pogorszyć sytuację. Nowe żądania połączeń muszą trafiać do innego węzła w klastrze, w którym działa ta usługa. Dokładnie to mówi mi wartość Wiadomość w alercie.
Zgodnie z tym dokumentem EM 12c, sekcja 4.3.2, Stan ryzyka analizy ciśnienia pamięci, tekst ostrzeżenia powinien zawierać nazwę serwera. Jednak powyższy tekst wiadomości nie mówi mi, na którym serwerze występuje problem. Na szczęście dla mnie jest to tylko dwuwęzłowy klaster RAC, więc nie mam zbyt wielu do zbadania.
Kiedy patrzę na wykorzystanie procesora, wszystko jest w porządku. Użycie swap jest praktycznie zerowe na obu węzłach. Wolna pamięć wynosi ponad 25% na obu węzłach. Ciekawe… po co w ogóle alert?
Za każdym razem, gdy otrzymuję ten alert, mogę wysłać kolejnego e-maila z informacją, że problem zostanie rozwiązany w ciągu kilku minut. Więc problem jest krótkotrwały. Jednak alerty wciąż się pojawiają.
Po pewnym badaniu okazuje się, że Oracle dokonało zmiany w Memory Guard w Grid Infrastructure 12.1.0.2. We wcześniejszych wersjach funkcja Memory Guard zajmowała się tylko bazami danych zarządzanymi przez zasady. W GI 12.1.0.2 Memory Guard zaczął dbać również o bazy danych zarządzane przez administratora. Moje bazy danych RAC są zwykle zarządzane przez administratorów, co jest jednym z powodów, dla których teraz to widzę.
Aby jeszcze bardziej zwiększyć problem, najwyraźniej GI 12.1.0.2 znał błąd 1582630, w którym ilość wolnej pamięci została obliczona niepoprawnie. Notatka 1929994.1 wymienia obejście i istnieje również poprawka. Zastosowałem obejście i rozwiązało mój problem. W niedalekiej przyszłości dostanę poprawkę do Testu, zanim przejdę do produkcji.
Na szczęście odkryłem to jeszcze dziś wieczorem przed aktualizacją GI. W przeciwnym razie zdenerwowałbym użytkowników końcowych, którzy mogliby mieć problemy z połączeniem z bazą danych. To tylko kolejny przykład tego, dlaczego mam dobrą platformę testową, dzięki której mogę wykrywać i rozwiązywać problemy przed wprowadzeniem zmiany w środowisku produkcyjnym.
