日本エクセム - 事例集01 -

MaxGauge（マックスゲージ）による分析事例 01

金融大手A社で発生した障害の分析事例 - データベースがハング状況に陥る

あるカード会社にて、システムの本番稼動初日のAM 10:00頃、処理の応答が帰らないクライアントが多発しました。クライアントの状況は軒並み「応答なし」となり、それ以降、実行された多くのクライアント処理も全て同じ状況に陥りました。

やむなくデータベースの再起動で対応を行いましたがすぐさま同様の状況に陥り、合計3度の再起動を行い対処を行いました。その後AM 11:30頃よりアクセスが減った事もありその日は何とか運用可能となったのですが、システム稼働初日に起きたこの問題は、これからのシステムの運用に大きな不安を残し一日も早く対処を行う必要が発生しました。

マックスゲージ事例


このシステムは、MaxGaugeを導入していた為、幸い障害時の稼働状況を非常に細かい部分まで記録できていました。これで次の日に障害再現待ちを行う必要はありません。即座に分析に入る事ができます。

ここでは、MaxGauegを利用した街頭障害の分析の流れをご紹介します。

MaxGaugeでの性能障害対応の流れ

次の図がMaxGaugeの障害解析作業の流れを図にした物です。

マックスゲージ事例

Oracleデータベースの障害対応は、障害時のボトルネックポイントを見極め、その原因を特定、原因を排除するで行われるのが一般的です。この解析のポイントは次の3つになります。

  • ●ボトルネックは、Wait Eventに現れる。
  • ●Waitの発生しているリソースがボトルネック。
  • ●時間のかかっているWait EventのTop5で、8割を占める。

これらを見極め、原因を追求する為には「システム全体」「その障害発生時点の状況」「その状況に関連していたセッション」「セッションが実行していたSQL」と全体から詳細へドリルダウンで問題を追求することが非常に効果的です。

このドリルダウン分析を実現するには、多くの情報と、その情報を効果的に結びつけ解析できる事が大きなポイントとなりますが、MaxGaugeは、そのドリルダウン分析に必要な情報と機能を両方提供しています。

MaxGaugeでのドリルダウン分析の手法を実際に解説します。

診断/分析

（1）OS指標での分析

  • User CPU の利用率が割合としては高いが、午後の稼動状況と比較しても悪影響があったとは断定できない
  • Memoryの利用状況は一定であり、特に変化は見られない
  • Buffer Cache Hit Ratioも、95％以上を保っており障害発生前後も変化がない

マックスゲージ事例

（2）障害発生時間帯（10:00～11:30）の待機情報のトップ１０を確認

  • 待機 Top１： DB FILE SEQUENCIAL READ　Top2：LATCH FREE
  • 待機 Top1 + Top2 にて、70%弱の待機時間を占める

マックスゲージ事例

（3）Top1、Top2の待機イベントの24時間トレンドを確認

  • DB FILE SEQUENCIAL READ　：　障害発生時間帯も他の時間の状況と変化はない
  • LATCH FREE　：　障害発生時間帯のLatchが極端に高い

マックスゲージ事例

（4）LATCH FREE発生の原因の想定

  • 多量のハードパースが発生する際に、LATCH FREEが発生する

（5）同時間帯のハードバース発生状況の確認

  • 「parse count　(hard)」が合計で「195,697」回、平均で「36.6」回/秒発生していた

マックスゲージ事例

（6）ハードパース発生原因の想定

  • SQLにリテラル値が含まれており、実行のたびに解析されてしまう

（7）同時間帯に実行されており、LATCH FREEを起こしていたセッションの実行SQLを確認

  • SQLにリテラル値が含まれていた

マックスゲージ事例

結果

障害発生時の待機情報およびそれらの原因となる要素状況の判断より、以下の状況が発生し、メモリ獲得競合待ちによるスローダウン現象が発生していた事がわかりました。

  • ■リテラルSQLの実行による「hard parse」の大量実施のため、ラッチ競合の発生
  • →shared pool latch、library cache latch、row cache object latch
  • ■リテラルSQLによる共有プールの非効率的な使用及び共有SQLのAge Out現象発生
  • ■リテラルSQLが共有プールに格納されAge Outを繰り返すことにより、メモリの断片化が進む
  • →空きメモリの検索、割当などに負荷を与える

また、リテラルSQLは、10:00～11:30に集中的に利用される一部のアプリケーションに多く存在していたため、11:30以降には現象が見られなくなった。

マックスゲージ事例

※「latch」待機イベントについて
SGA内部のメモリに対しての一種のロック（LOCK）で、排他制御を行い、多数のプロセスの同時アクセスによる潜在的な衝突からメモリ構造を保護する。主に、SGAの特定メモリ構造体に対するアクセス、あるいはメモリの割当時に使われる。全てのプロセスは、SGAにアクセスするために、特定ラッチを獲得しなければいけない。該当のラッチが他のプロセスによって使用中の場合、当該待機イベントが発生する。

改善策

アプリケーションの改修が可能な場合

  • ■リテラルSQLをバインド変数を使うように修正

アプリケーションの改修が難しい場合

  • ■初期化パラメータ「CURSOR_SHARING=FORCE」設定（8.1.6から可能）
  • －SQL修正ができない場合使用
  • －システム、セッションレベルで動的設定も可能
  • －9iから、「SIMILAR」オプション及び「CURSOR_SHARING_EXACT」ヒントも指定可能
  • －注意 ： リテラルSQLの実行計画と異なる可能性がある、DSSシステムなどでは推奨しない
  • ■共有プールを定期的に初期化する ： メモリの断片化の解消
  • －ALTER SYSTEM FLUSH SHARED_POOL;
  • －SQL修正ができなく、SQLの量が多い場合
  • －事前によく使われるPL/SQLなどは「FLUSH」されないようにメモリにキープしておく

効果

改善策でのアプリケーション改修を行った結果、「Hard Parse」が必要最小限に収まり、データベースのハング現象の改善が図られました。

その他の検討事項

同様のLATCH FREEの増加現象が、15:30前後でも発生しており、アクセスの集中度合いにより同様のハングが発生する可能性があるため、アプリケーションの修正を要すると思われます。