J'ai une base de données de test qui est un système RAC à 2 nœuds. Je travaille dans le but d'obtenir la base de données de production vers Oracle 12.1.0.2 dans un délai d'environ un mois. Cela signifie bien sûr que je dois mettre à jour l'infrastructure de grille avant la mise à niveau de la base de données. J'ai mis à jour GI sur mon cluster de secours et sur ma base de données de test également. La mise à niveau primaire du GI est prévue pour ce soir.
Depuis que j'ai mis à jour GI dans Test il y a quelques semaines, je reçois des alertes d'EM12c similaires à celles-ci :
Hôte=hôte01
Type de cible=Cluster
Nom cible=test-scan
Catégories=Affaires
Message=Le serveur subit une pression de mémoire élevée et les services sur toutes les instances de ce serveur seront arrêtés
Gravité=Avertissement
Heure de l'événement signalé =29 juillet 2015 13:05:13 HAC
Système d'exploitation=Linux
Plateforme=x86_64
Type d'événement=Alerte de métrique
Nom de l'événement=wlm_event :wlm_qosm_mpa_risk_state
Metric Group=Événements QoS
Metric=État de risque d'analyse de la pression de la mémoire
Valeur métrique=ROUGE
Certains détails de l'alerte ont été supprimés par souci de brièveté.
Alors d'où cela vient-il ? Pourquoi cela signifie-t-il pour moi ?
Cette erreur provient de la qualité de service (QoS) d'Oracle dans Grid Infrastructure. Il s'appuie sur les informations de Cluster Health Monitor (CHM). Plus précisément, cette alerte provient de Memory Guard. Pour plus d'informations sur Memory Guard, consultez ce PDF, en particulier la fin de la deuxième page.
Memory Guard essaie de me sauver de moi-même, et comme nous le verrons, il fait un mauvais travail. L'idée est que lorsque le serveur a une pression de mémoire, Memory Guard mettra tous les services sur ce nœud hors service. Autoriser davantage de connexions consommerait encore plus de mémoire et pourrait aggraver la situation. Les nouvelles demandes de connexion doivent être dirigées vers un autre nœud du cluster exécutant ce service. C'est exactement ce que me dit la valeur Message dans l'alerte.
Selon ce document EM 12c, section 4.3.2, Memory Pressure Analysis Risk State, le texte d'alerte est censé contenir le nom du serveur. Pourtant, le texte du message ci-dessus ne me dit pas quel serveur rencontre le problème. Heureusement pour moi, il ne s'agit que d'un cluster RAC à 2 nœuds, donc je n'en ai pas trop à examiner.
Quand je regarde l'utilisation du processeur, tout va bien. L'utilisation du swap est pratiquement nulle sur les deux nœuds. La mémoire libre est supérieure à 25 % sur les deux nœuds. Curieux... pourquoi l'alerte en premier lieu ?
Chaque fois que je reçois cette alerte, je peux envoyer un autre e-mail indiquant que la condition est résolue en quelques minutes. Le problème est donc de courte durée. Pourtant, les alertes continuent d'arriver.
Il s'avère, après quelques recherches, qu'Oracle a modifié Memory Guard dans Grid Infrastructure 12.1.0.2. Dans les versions antérieures, Memory Guard ne s'occupait que des bases de données gérées par des règles. Dans GI 12.1.0.2, Memory Guard a également commencé à s'occuper des bases de données gérées par l'administrateur. Et mes bases de données RAC sont généralement gérées par l'administrateur, ce qui est l'une des raisons pour lesquelles je vois cela maintenant.
Pour ajouter encore au problème, apparemment, GI 12.1.0.2 a connu le bogue 1582630 où la quantité de mémoire libre est calculée de manière incorrecte. Remarque 1929994.1 répertorie une solution de contournement et il existe également un correctif. J'ai appliqué la solution de contournement et cela a résolu mon problème. Je ferai appliquer le correctif à Test avant de passer à la production dans un avenir pas trop lointain.
Heureusement, j'ai découvert cela avant la mise à niveau de ma production GI plus tard ce soir. Sinon, j'aurais eu des utilisateurs finaux contrariés qui auraient pu rencontrer des problèmes de connexion à la base de données. Ce n'est qu'un exemple de plus de la raison pour laquelle j'ai une bonne plate-forme de test avec laquelle découvrir et résoudre les problèmes avant que le changement ne soit effectué en production.
