Имам тестова база данни, която е RAC система с 2 възела. Работя за целта да изкарам производствената база данни до Oracle 12.1.0.2 за период от около месец. Това разбира се означава, че трябва да надстроя Grid Infrastructure преди надстройката на db. Надстроих GI в моя резервен клъстер и в моята база данни за тестове. Основното надграждане на GI е насрочено за тази вечер.
Откакто надстроих GI в Test преди няколко седмици, получавам сигнали от EM12c, подобни на следното:
Хост=host01
Тип насочване=Клъстер
Име на целта=тестово сканиране
Категории=Бизнес
Message=Сървърът е под повишен натиск върху паметта и услугите на всички инстанции на този сървър ще бъдат спрени
Тежест=Предупреждение
Час на докладване на събитието=29 юли 2015 г. 13:05:13 ч. CDT
Операционна система=Linux
Платформа=x86_64
Тип събитие=Сигнал за показатели
Име на събитие=wlm_event:wlm_qosm_mpa_risk_state
Метрична група=QoS събития
Метрична стойност=Състояние на риска при анализ на налягането на паметта
Метрична стойност=ЧЕРВЕНО
Някои от подробностите за сигнала бяха премахнати за краткост.
И така, откъде идва това? Защо това означава за мен?
Тази грешка идва от качеството на услугата (QoS) на Oracle в Grid Infrastructure. Той разчита на информация за Cluster Health Monitor (CHM). По-конкретно, този сигнал идва от Memory Guard. За малко информация относно Memory Guard вижте този PDF, по-конкретно края на втората страница.
Memory Guard се опитва да ме спаси от мен самия и както ще видим, върши зле работа. Идеята е, че когато сървърът има напрежение в паметта, Memory Guard ще изведе всички услуги на този възел извън обслужване. Разрешаването на повече връзки би погълнало още повече памет и би могло да влоши ситуацията. Новите заявки за свързване трябва да отидат към друг възел в клъстера, изпълняващ тази услуга. Точно това ми казва стойността Message в предупреждението.
Съгласно този документ EM 12c, раздел 4.3.2, Състояние на риска при анализ на налягането в паметта, текстът на предупреждението трябва да съдържа името на сървъра. И все пак текстът на съобщението по-горе не ми казва кой сървър има проблема. За мое щастие, това е само RAC клъстер с 2 възела, така че нямам много за преглед.
Когато гледам използването на процесора, всичко е наред. Използването на суап е практически нулево и на двата възела. Свободната памет е повече от 25% и на двата възела. Любопитно… защо на първо място сигналът?
Всеки път, когато получа това предупреждение, мога да получа друг имейл, който казва, че състоянието е изчистено в рамките на няколко минути. Така че въпросът е краткотраен. Но сигналите продължават да идват.
След известно разследване се оказва, че Oracle е направил промяна в Memory Guard в Grid Infrastructure 12.1.0.2. В по-ранните версии Memory Guard се грижи само за управлявани от политики бази данни. В GI 12.1.0.2 Memory Guard започна да се грижи и за бази данни, управлявани от администратор. И моите RAC бази данни обикновено се управляват от администратор, което е една от причините, поради които виждам това сега.
За да добавим допълнително към проблема, очевидно GI 12.1.0.2 е знаел грешка 1582630 където количеството свободна памет е изчислено неправилно. Забележка 1929994.1 изброява заобиколно решение и има и корекция. Приложих заобикалящото решение и то реши проблема ми. Ще приложа корекцията към Test, преди да продължа с производството в недалечно бъдеще.
За щастие открих това преди надграждането на производствения GI по-късно тази вечер. В противен случай щях да имам разстроени крайни потребители, които може да са имали проблеми при свързването с базата данни. Това е само още един пример защо имам добра тестова платформа, с която да откривам и разрешавам проблемите, преди промяната да бъде направена в производството.
