Performance Analyzer(28)～Perfomance Analyser分析機能紹介17～

MaxGauge機能紹介

MaxGauge Performance Analyzerは、Oracleデータベースの稼働状況を事後分析できるツールです。

MaxGaugeの特徴は、Oracleデータベースで実際に稼働したセッション、SQLの明細を秒単位でスナップショットとして記録しておくことで、「何時、何分、何秒」になにが起きていたのかの状況把握や、どのSQLが原因で問題が起きていたのかの原因調査を行い対応することができるようになることです。
データベース運用者だけでなく、開発者もご利用いただけ、開発・運用の効率化、スピードアップを図れます。

MaxGauge Performance Analyzerは、性能および障害分析を簡単にできるようにしていきます。

---

今回も引き続き、 Performance Analyzerの分析機能を紹介していきます。

■負荷が高い時間帯の原因を探る　（昨日の夕方遅かった）

〇絶対的な処理量が多かったか？

パフォーマンスアナライザー 推移分析：1日サマリー画面より、以下のステップで分析します。

① 昨日の日付を選択し検索します。

② DB処理量のグラフ推移より、全般的に夕方に負荷が上がっているのがわかります。

③ 主要指標グラフ部分で、一番負荷が高い時間のグラフバーの19時台のグラフバーをクリックします。

④ 下部リストにて、スキーマ、プログラム、モジュール、SQLの「Topリスト」が表示されます。

　一番処理量が多かったSQLは、全体の40%を占めていたことがわかります。

■負荷が高い時間帯の原因を探る　（昨日の夕方遅かった）

〇滞留が多く発生していたか？

パフォーマンスアナライザー 推移分析：1日サマリー ： ボトルネックタブ画面より、以下のステップで分析します。

① 一日サマリー画面で、「ボトルネック」タブを選択します。

② 一日のアクティブセッション、ロック、および待機イベントの推移がグラフで表示されます。

　　同様に、19時で一番待機イベントが多いことが確認できます。

③ 19時台のグラフバーを選択します。

　　下部リストに、19時台の待機イベントの状況が表示されます。

④ 待機イベントのTopを確認すると、「enq:TX – row lock contention」であることがわかります。

⑤ 「enq:TX – row lock contention」をクリックすると、その時間帯でこの待機イベントを発生させた

　　SQLがリストアップされます。

　　この待機イベントは、ロック発生の待機イベントのため、ロックの状況を深堀していきます。

⑥ ロックセッションも19時台は多く発生していることから、19時台のグラフバー上で右クリックを

　　行い、1時間の詳細画面へドリルダウンします。

■負荷が高い時間帯の原因を探る　（昨日の夕方遅かった）

〇ロックなど他の処理で待たされていたか？

①メインの指標の流れを見て目立ったところがないことを確認。ロックを確認するので「ロック待機セッション」タブを開きます。

②　1時間のグラフで、ロック数が多かったところをダブルクリックします。　下部リストに、その時の状況が表示されます。

■アラートが上がった後、状況を調べる

監視はしていても、アラート発生後の原因調査では、いちから情報収集をしているシステムが多い状況です。

MaxGaugeにより、蓄積した稼働情報からすぐに原因調査に係れます。

監視設定にてアラートが上がった際の確認方法ステップは以下となります。

パフォーマンスアナライザー 推移分析：アラート画面より、以下のステップで分析します。

推移分析

① 過去1か月のアラート発生状況を検索します。

② Oracleのアラートログには何も表示されないため、何も発生していないことを確認しました。

③ MaxGaugeで設定したアラートでは、アクティブセッションのアラートが定期的に発生していることが確認できます。

　1日をとってみて、昨日の8:50の状況を、性能トレンド機能で調べてみます。（この場合、19:49）

③ ロックツリータブを開きます。 ロックホルダーと、ロック待ちセッションがツリー上で確認できます。

　　（※例の場合、19:49:00ではロックは発生していなかったため、下部秒リストから、ロックが発生していた「34秒」を選択し表示）

④ ロックの発生状況を確認します。

　ロックホルダーは、「Update」処理を行い、「Log File Sync」待ちの状態でした。

　（※Log File Syncは、LGWRがRedoエントリをディスクへ記録し終わるまで待機となります。）

　そのため、Updateが頻繁に行われていたため、REDOエントリの書き込み処理で多くの処理が待たされていた

こと がわかりました。

このように、MaxGaugeの活用により、ピンポイントでの原因調査が可能となります。

■アラートが上がった後、状況を調べる

④ 昨日の20時台の性能トレンドを開きます。

⑤ アクティブセッションタブを開き、数値が上がっている個所を確認します。

　　数値が上がっている個所をダブルクリックします。

⑥ 39秒の時点で数値が上がっていることがわかります。39秒のグラフバーをダブルクリックします。

⑦ 多くのセッションが、Update処理を行い、完了待ちであることがわかります。

　　前項と同様、REDOの書き込み待ちで一時的にアクティブセッションが待たされていたことが確認できます。

■トラブルがあった時間の原因を探る　（昨日22時00分ごろにエラーと連絡がある）

トラブルの場合には、ピンポイントで時間を把握できることがあります。

MaxGaugeにより、その時間の稼働状況を正確に確認することができます。

パフォーマンスアナライザー 推移分析：性能トレンド画面より、以下のステップで分析します。

① 昨日22：00前後の範囲で全体の稼働状況を確認します。

② CPUが、22：00に急に上がっており、80%の使用量になっているのが確認できます。

③ 下のセッションリストより、CPUを一番使っているセッションは、Oracleのバックグラウンドで、OEM系のSQLが実行され多く使っていたことが確認されました。

この処理が原因で、他のアプリケーションでエラーとなっていた可能性が考えられます。

---