目次
今回は
みなさん、こんにちはMaxGaugeを販売しております日本エクセムの製品担当です。
今回はデータベースで発生したパフォーマンス問題などのトラブル分析例を紹介します。
MaxGaugeを使えば一般的な監視ツールやStatspack、AWR report などによる分析と比較して
短時間で問題原因や要因を簡単に調査することが出来ます。
トラブル発生、何から調べたら良いの？
データベースのトラブルは突然やってきます。
データベース高負荷、スローダウン状態、SQL実行遅延（アプリケーション処理遅延） など事象は様々ですが
重要なのは『事象発生時の状況を正しく把握する事』です。
状況を正しく把握するには当時の稼働状況のデータが必要になり、MaxGaugeにはその情報を収集して事後で確認することが出来ます。
トラブルの要因や原因を探す
MaxGaugeを使用して発生したトラブルの要因や原因を分析していく汎用的な手順を紹介します。
使用する機能はMaxGaugeの事後分析が出来る「パフォーマンスアナライザ」の「性能トレンド」機能をつかって、トラブル分析の主なポイントを確認していきます。
トラブル発生時のデータのデータを表示するMaxGaugeのパフォーマンスアナライザからトラブル発生時のデータを表示します
①推移分析 をクリック
②性能トレンド をクリック
③画面上段にあるカレンダーからトラブル発生時の時間を選択して検索
④詳細情報を表示するためグラフをドラック＆ドロップすると選択範囲内の詳細データが表示される画面へ遷移します
遷移した詳細画面でいくつかの確認ポイントから分析していきます。
CPU使用率を確認
CPU使用率の推移を確認します。画面上段にある [CPU] タブをクリックするとデータベースサーバのOSのCPU使用率が表示されます。
画面下段にある [プロセス] タブをクリックすると実行していたOSプロセスの一覧を確認することが出来ます。
データベース以外のサービスが実行する環境では「データベースの処理が起因」or「データベース以外の処理が起因」を切り分けすることが出来ます。
| 確認ポイント |
|---|
|
待機クラス/待機イベントを確認
待機クラスを確認することでデータベースの処理がどの分類で時間を費やしていたかを確認することが出来ます。
画面上段にあるタブの [待機クラス] タブをクリックして表示します。
画像の例では全体的に「User I/O」の値が高く主にSQL実行によるI/O処理時間が多いことを推測することが出来ます。
待機クラスの元となる待機イベントを確認することで時間を費やしているデータベース処理の詳細を確認することが出来ます。
画面中段にある [上位待機指標] タブをクリックして発生していた待機イベントを確認します。
画像の例では「direct path read」の待機イベントの値が高く、「direct path read」の特性から「実行するSQLがディスクから直接データを読取している」処理時間が大きいことを推測することが出来ます。
| 確認ポイント |
|---|
|
MaxGaugeで表示されている待機クラスや待機イベントの詳細はOracleデータベースのマニュアルを参照してください。
待機イベントに関しては少し難しい部分がありますがトラブルの詳細分析には必須となります。
日本エクセムでは待機イベントを分かりやすく紹介しております。
マニュアルでは理解が難しかったら是非読んでみてください。
アクティブセッションの確認
アクティブセッションを確認することで実行されていたSQLやセッション情報を確認することが出来ます。
アクティブセッションの情報はトラブル分析には有効な情報で「遅延したSQL」、「トラブルの原因となったSQL」、「トラブル発生時に実行されていたSQL」などMaxGaugeによる分析の中心となる機能です。
アクティブセッションを確認する前に画面上段にある [アクティブユーザセッション] のタブからSQLを実行中のセッション数の推移を確認します。
アクティブユーザセッションはトラブル分析には重要な指標です。
アクティブユーザセッションの値はデータベースでSQLを同時実行していたセッション数となり
言い換えればデータベース処理の混雑状況と判断することが出来ます。
アクティブユーザセッション数が上昇している時間帯では「SQLの処理遅延」や「CPU使用率の上昇」や「待機クラス / 待機イベントの値の上昇」 などが同時に発生しているケースが多いです。
アクティブユーザセッションが上昇している時間帯がありましたら画面下段にある [アクティブセッション] タブをクリックするとSQLを実行していたセッションリストが表示されます。
セッションリストの下にある棒グラフは1秒単位のアクティブセッション数を示しグラフをクリックすることで、毎秒のセッションリスト表示を切り替えることが出来ます。
セッションリストの「Elapsed Time (Sec)」を降順で並び替えることで実行時間が長いSQLを特定することが出来ます。
実行時間が長いSQLが多い場合アクティブセッション数が上昇してデータベース処理が混雑した状態になるケースが多いです。
また実行時間が長いSQLがトラブルの起因となっている可能性があるので要確認となります。
実行していたSQLの詳細を確認したい場合は右クリックメニューから [SQL詳細] から対象SQLの統計値を確認することが出来ます。
対象SQLの平均時間や実行回数などを確認することが出来ます。
他の時間と相対的に比較してSQL処理遅延の発生状況などを確認することが出来ます。
アクティブセッションリストの横に [1分詳細分析] ボタンをクリックすると1分間アクティブセッションで発生した待機イベントなどを集計した分析ができます。
1秒間隔にセッションで発生した待機クラス/待機イベントで集計されることから実行していたSQLのボトルネックの把握に役立ちます。
| 確認ポイント |
|---|
|
アクティブセッションが滞留する例
アクティブセッション数が増えて処理が滞留する場合、上記の推移で増加する傾向が多くみられます。
アクティブセッション数が徐々に増加して解消するパターンでセッションの滞留した原因を調査するには
以下のポイントを確認することで滞留の要因や原因を分析出来るケースが多いです。
- セッションの滞留が始まる時間のセッション一覧を確認、画像の例では30秒辺りで実行されていたSQLが滞留の要因や原因となっている場合があるので確認します。
- セッション数が最大数になったときのセッション一覧を確認、各セッションの待機イベントに注目して多く発生している待機イベントから滞留の原因・要因を推測することが出来ます。
また実行時間が長いSQLのセッションにも注目して実行しているSQLが滞留の起因となっていないか確認します。 - セッションの滞留が解消した時間、画像の例では53秒頃のセッションを確認。
1秒前の52秒に実行中で53秒には終了しているセッションに注目、終了したセッションが滞留の起因や要因となっているケースがあるので確認します。
OracleのバックグランドプロセスやOS側の影響で上記のような滞留が発生するケースもありますので
一概にこの調査方法で原因まで辿りつけることはありませんが、特定のセッションやSQL実行が要因で滞留するケースでは分析可能と考えております。
その他確認ポイント
今回紹介しました確認ポイント以外に事象によっては「ロック待機セッション」、「SQL実行統計」、「SQLランキング」などの分析が有効な場合があります。
最後に
今回はMaxGaugeのパフォーマンスアナライザを利用した汎用的なトラブル調査手順を紹介しました。
待機イベントなどの分析もあり少々難しく感じるかもしれませんが、基本的にはアクティブセッションを中心に確認することで、トラブルの要因や原因を特定可能なケースが多く
DB管理者だけでなくアプリケーション開発担当者、システム運用担当者でも簡単に分析が出来て、MaxGaugeを様々な場面で活用することが出来ます。
いかがでしたでしょうか。
次回の記事もお楽しみにしていてくださいね♪
※過去の記事はこちらです。
投稿者プロフィール
