Eu tenho um banco de dados de teste que é um sistema RAC de 2 nós. Estou trabalhando com o objetivo de levar o banco de dados de produção para o Oracle 12.1.0.2 em cerca de um mês. Obviamente, isso significa que tenho que atualizar a infraestrutura de grade antes da atualização do banco de dados. Eu atualizei o GI no meu cluster de espera e no meu banco de dados de teste também. A atualização primária do GI está agendada para esta noite.
Desde que atualizei o GI in Test algumas semanas atrás, tenho recebido alertas do EM12c semelhantes ao seguinte:
Host=host01
Tipo de destino=Cluster
Nome do destino=verificação de teste
Categorias=Negócios
Message=O servidor está sob pressão de memória elevada e os serviços em todas as instâncias neste servidor serão interrompidos
Gravidade=Aviso
Hora do evento relatado=29 de julho de 2015 13:05:13 CDT
Sistema Operacional=Linux
Plataforma=x86_64
Tipo de evento=Alerta de métrica
Nome do evento=wlm_event:wlm_qosm_mpa_risk_state
Grupo de métricas=Eventos de QoS
Metric=Estado de risco da análise de pressão da memória
Valor da métrica=VERMELHO
Alguns detalhes do alerta foram removidos por questões de brevidade.
Então, de onde vem isso? Por que isso significa para mim?
Este erro vem do Quality of Service (QoS) da Oracle em Grid Infrastructure. Ele se baseia nas informações do Monitor de integridade do cluster (CHM). Mais especificamente, este alerta vem do Memory Guard. Para obter algumas informações sobre o Memory Guard, consulte este PDF, especificamente o final da segunda página.
O Memory Guard está tentando me salvar de mim mesmo e, como veremos, está fazendo um péssimo trabalho. A ideia é que, quando o servidor tiver pressão de memória, o Memory Guard colocará todos os serviços nesse nó fora de serviço. Permitir mais conexões consumiria ainda mais memória e poderia piorar a situação. Novas solicitações de conexão devem ir para outro nó no cluster que executa esse serviço. Isso é exatamente o que o valor Message no alerta está me dizendo.
De acordo com este documento EM 12c, seção 4.3.2, Estado de risco de análise de pressão de memória, o texto de alerta deve conter o nome do servidor. No entanto, o texto da mensagem acima não me diz qual servidor está tendo o problema. Felizmente para mim, é apenas um cluster RAC de 2 nós, então não tenho muitos para examinar.
Quando eu olho para a utilização da CPU, tudo está bem. O uso de swap é praticamente zero em ambos os nós. A memória livre é superior a 25% em ambos os nós. Curioso… por que o alerta em primeiro lugar?
Toda vez que recebo esse alerta, posso enviar outro e-mail que diz que a condição foi esclarecida em alguns minutos. Então a questão dura pouco. No entanto, os alertas continuam chegando.
Acontece que, após algumas investigações, a Oracle fez uma alteração no Memory Guard no Grid Infrastructure 12.1.0.2. Em versões anteriores, o Memory Guard cuidava apenas de bancos de dados gerenciados por políticas. No GI 12.1.0.2, o Memory Guard também começou a cuidar dos bancos de dados gerenciados pelo administrador. E meus bancos de dados RAC geralmente são gerenciados pelo administrador, que é uma das razões pelas quais estou vendo isso agora.
Para aumentar ainda mais o problema, aparentemente, o GI 12.1.0.2 conhece o Bug 1582630 em que a quantidade de memória livre é calculada incorretamente. Observação 1929994.1 lista uma solução alternativa e também há um patch. Apliquei a solução e resolveu meu problema. Vou aplicar o patch ao Test antes de prosseguir para a produção em um futuro não muito distante.
Felizmente, descobri isso antes da atualização do meu GI de produção mais tarde hoje à noite. Caso contrário, eu teria incomodado os usuários finais que podem ter tido problemas para se conectar ao banco de dados. Este é apenas mais um exemplo do motivo pelo qual tenho uma boa plataforma de teste para descobrir e resolver os problemas antes que a alteração seja feita na produção.
