2ノードのRACシステムであるテストデータベースがあります。私は、約1か月の期間で本番データベースをOracle12.1.0.2に移行するという目標に向かって取り組んでいます。これはもちろん、データベースをアップグレードする前にグリッドインフラストラクチャをアップグレードする必要があることを意味します。スタンバイクラスターとテストデータベースでもGIをアップグレードしました。プライマリGIのアップグレードは今夜に予定されています。
数週間前にテストでGIをアップグレードして以来、EM12cから次のようなアラートを受け取っています。
Host = host01
ターゲットタイプ=クラスター
ターゲット名=テストスキャン
カテゴリ=ビジネス
メッセージ=サーバーのメモリ負荷が高くなり、このサーバー上のすべてのインスタンスのサービスが停止します
重大度=警告
イベント報告時間=2015年7月29日午後1時5分13秒CDT
オペレーティングシステム=Linux
Platform = x86_64
イベントタイプ=メトリックアラート
イベント名=wlm_event：wlm_qosm_mpa_risk_state
メトリックグループ=QoSイベント
Metric=メモリ圧力分析のリスク状態
メトリック値=赤
簡潔にするために、アラートの詳細の一部が削除されました。
それで、これはどこから来ているのですか？なぜそれが私にとって意味があるのですか？
このエラーは、グリッドインフラストラクチャにおけるOracleのサービス品質（QoS）が原因で発生します。これは、クラスターヘルスモニター（CHM）情報に依存しています。具体的には、このアラートはMemoryGuardから送信されます。 Memory Guardの詳細については、このPDF、特に2ページ目の終わりを参照してください。
メモリーガードは私を自分自身から救おうとしています、そして私たちが見るように、それはそれの貧弱な仕事をしています。サーバーにメモリ不足が発生すると、MemoryGuardはそのノード上のすべてのサービスをアウトオブサービスにするという考え方です。より多くの接続を許可すると、さらに多くのメモリが消費され、状況が悪化する可能性があります。新しい接続要求は、そのサービスを実行しているクラスター内の別のノードに送信する必要があります。これはまさにアラートのメッセージ値が私に伝えていることです。
このEM12cドキュメントのセクション4.3.2、メモリ圧力分析のリスク状態によると、アラートテキストにはサーバー名が含まれていると想定されています。しかし、上記のメッセージテキストは、どのサーバーに問題があるのかを教えてくれません。幸いなことに、これは2ノードのRACクラスターしかないため、調査する数が多すぎません。
CPU使用率を見ると、すべて問題ありません。スワップの使用量は、両方のノードで実質的にゼロです。空きメモリは両方のノードで25％以上です。好奇心が強い…そもそもなぜアラートなのか？
このアラートを受け取るたびに、数分以内に状態が解消されたことを知らせる別のメールを送信できます。したがって、この問題は短命です。それでもアラートは届き続けます。
調査の結果、OracleがGridInfrastructure12.1.0.2のMemoryGuardに変更を加えたことが判明しました。以前のバージョンでは、MemoryGuardはポリシー管理されたデータベースのみを管理していました。 GI 12.1.0.2では、MemoryGuardは管理者が管理するデータベースの管理も開始しました。そして、私のRACデータベースは通常、管理者によって管理されています。これが、私が今これを目にしている理由の1つです。
この問題をさらに追加するために、明らかに、GI 12.1.0.2はバグ1582630を認識しており、誤って計算された場合に空きメモリの量が発生します。注1929994.1には回避策が記載されており、パッチもあります。回避策を適用したところ、問題は解決しました。それほど遠くない将来に本番環境に進む前に、パッチをテストに適用します。
ありがたいことに、私は今夜遅くに本番GIをアップグレードする前にこれを発見しました。そうしないと、データベースへの接続で問題が発生した可能性のあるエンドユーザーを混乱させることになります。これは、本番環境で変更が行われる前に問題を発見して解決するための優れたテストプラットフォームがある理由のもう1つの例です。