データベースのレスポンス・タイム分析(RTA)


データベースにおけるレスポンス・タイム(応答時間)分析(RTA:Response time analysis)はすべてのウェイト、キュー、時間についての分析になります。

RTAのコアはウェイト・イベントかウェイト・タイプです。サーバ・プロセスやスレッドがSQLクエリーを続けて処理できる前に完了したイベントや利用可能になったリソースを待たなければならない時に、これをウェイト・イベントと呼びます。例としてバファーへ移動するデータ、ディスクへの書込み、ロックでの待ち、ログ・ファイルへの書込みがあります。通常何百のウェイト・イベントはクエリーとレスポンス(応答)間で受け渡さなければなりません。

もしSQLクエリーが通常以上の特別なウェイト・イベントで待ちが発生している場合、それをどうやって見つけますか?それが何か判りますか?その待ちの理由をどのように見つけますか?どのように修正しますか?それがRTAの出番です。

RTAは各クエリー用の全てのウェイト・イベントの時間を計測し、他のクエリに応じた、そして時間に応じたこのデータを可視化する手法を提供し、エンドユーザに最もインパクトを与える効率をプライオリティ化できます。

RTAを活用するには、次のステップを踏む必要があります。
ignite8_01
1. 遅延を起こしている特定のウェイト・イベントを識別する。
可能性のある問題点とボトルネックを分離できるように個別に全てのウェイト・イベントを計測する必要があります。

2.遅延を起こしている特定のクエリーの識別
もしインスタンス全体が遅れている場合は遅延、ボトルネックを起こしている特定のクエリーを分離することは困難です。パフォーマンス・モニター・ツールとダッシュボードが多重のSQLステートメントをまとめて平均的なアセスメントを提供るツールもあります。しかし平均データを確認しても、どの特定のSQLステートメントがパフォーマンスを遅延させているかの判断は難しいです。RTAアプローチを活用させるためには個別のSQLステートメント・レベルでパフォーマンス統計を収集する必要があります。

3.遅延のタイム・インパクトの測定
ユーザはタスクを完了させ、次のプロセスに受け渡すまでのウェイト・イベント・タイムを計測する必要があります。この情報が無ければ何がボトルネックを引き起こしているか完全には理解はできません。

全てのこれらの情報を使えるようにするすれば、ユーザは各SQLとSQLが利用する各リソースを把握することができます。そしてデータベースの内外部での遅延の根本原因を正確にピンポイントすることができます。

RTA用の最適で持続的なパフォーマンス・モニター・ツールは次の基準が必要です。

●RTAに必要なキー項目を識別・計測(もしツールがこれらすべてを提供しなければ、RTAは満たせません。)
・遅延を起こしている特定のSQLクエリーの識別
・遅延を起こしている特定のボトルネック(ウェイト・イベント)の識別
・識別したボトルネックの影響時間の表示
ツールがどのようにデータを収集し、どこからデータを収集するかを特に注意することが重要です。
●通事的な分析データにアクセスできる途切れない24×7モニターの提供
●システムに対するわずかな負荷で、1%以下(いくつかのツールではパフォーマンス・データ取得にトレースを使用し、モニター・サーバに負荷を引き起こします。)
●開発者やマネージャのようなDBA(データベース管理者)以外でも使用可能なこと。次の質問を確認してください。
・DBA以外の人間でも使用し、理解することが簡単かどうか?
・ユーザが本番データベースへのアクセスが必要かどうか?これらすべての要望に適合できなければ、RTA実行に制限されて使用されます。

これらの要求を満たさなければ、RTAの実行では使用制限があるツールといえます。

今こそレスポンス・タイム分析(RTA)を!

RTAはユーザ経験に起因するパフォーマンスを見つけ、計測する体系的な手法です。RTAはエンド・ツー・エンドのクエリー、リクエストからレスポンスへ、その間に遭遇するすべてのウェイト、プロセス中のクエリーで使用されるすべてのリソースを計測します。RTAはこの情報を他のクエリーと共にコンテクストに入れ、エンドユーザに大きなインパクトを与えるボトルネックを検知・修正するためのヒストリカルな傾向情報を提供します。RTAはデータベースのチューニングを夜や週末の遅くに危機モードで行われる後手後手の処理からエンドユーザにサービスするという先を見越した実践へと転換させます。

関連したトピックス