SQL Server 拡張イベントの概要
SQL Server 拡張イベントは、サーバー システムの汎用的なイベント処理システムです。拡張イベント インフラストラクチャでは、SQL Server からのデータを相互に関連付けることができます。さらに、特定の条件下では、オペレーティング システムやデータベース アプリケーションからのデータを相互に関連付けることもできます。後者の場合、イベント データをオペレーティング システムまたはアプリケーションのイベント データと相互に関連付けるためには、拡張イベント出力を Event Tracing for Windows (ETW) に送る必要があります。
すべてのアプリケーションには、アプリケーションの内部と外部の両方で有用な実行ポイントが存在します。アプリケーションの内部に目を向けると、非同期処理が、タスクの初回実行時に収集された情報を使ってキューに格納されていることがあります。一方、アプリケーションの外部では、実行ポイントは、監視ユーティリティに対し、監視対象アプリケーションの動作やパフォーマンス特性に関する情報を提供します。
拡張イベントを使用すると、プロセスの外部でイベント データを利用できます。このデータは通常、次のようなツールやユーザーによって使用されます。
トレース ツール (SQL Trace、システム モニタなど)。
ログ ツール (Windows イベント ログ、SQL Server エラー ログなど)。
製品を管理するユーザー、または製品上でアプリケーションを開発するユーザー。
拡張イベントのデザインと機能
拡張イベントの設計には、次の大きな特徴があります。
拡張イベント エンジンはイベントの種類に依存しません。イベントの内容による制約を受けないため、あらゆるイベントをあらゆるターゲットにバインドできます。拡張イベント エンジンの詳細については、「SQL Server 拡張イベント エンジン」を参照してください。
イベントは、イベント コンシューマ (拡張イベントのターゲット) とは分離されています。つまり、任意のターゲットが任意のイベントを受け取ることができます。さらに、ターゲット側では、発生したあらゆるイベントを自動的に処理できるため、追加のイベント コンテキストを提供したりログに記録したりすることが可能となります。詳細については、「SQL Server 拡張イベント ターゲット」を参照してください。
イベントは、イベントが発生した際に実行されるアクションとは異なります。したがって、すべてのイベントには任意のアクションを関連付けることができます。
述語を使用すると、イベントの発生を動的にフィルタ処理できます。この機能が拡張イベント インフラストラクチャの柔軟性を高めています。詳細については、「SQL Server 拡張イベント パッケージ」を参照してください。
拡張イベントはイベント データを同期的に生成します。また、そのデータは非同期的に処理できるため、柔軟なイベント処理が可能となります。さらに、拡張イベントには、次の機能が用意されています。
サーバー システムの枠を越えてイベントを処理する統一的なアプローチ。それと同時に、ユーザーは特定のイベントを切り分けて、トラブルシューティングに役立てることができます。
既存の ETW ツールのサポートと統合。
Transact-SQL に基づく自由な構成が可能なイベント処理メカニズム。
アクティブ プロセスを最小限の負荷で動的に監視する機能。
拡張イベントと ETW の使用
拡張イベントを使用してオペレーティング システムやデータベース アプリケーションからのデータを相互に関連付けるには、ETW を活用するための知識を身に付けておくことをお勧めします。ETW は、拡張イベントと組み合わせて使用したり、拡張イベントのイベント コンシューマとして使用したりできます。ETW の背景情報については、次のトピックを参照してください。
拡張イベントの使用に関するシナリオ
拡張イベントには、監視やトラブルシューティングを目的とした幅広い用途があります。拡張イベントを使用すると、各種の問題を解決するための貴重なデータを得ることができます。ここでは、拡張イベントを有効活用できるシナリオをいくつか紹介します。
作業セットのトリミングのトラブルシューティング。
過度に高い CPU 使用率のトラブルシューティング。
デッドロックのトラブルシューティング。
要求アクティビティと Windows ETW ログとの関連付け。
作業セットのトリミングのトラブルシューティング
実稼働サーバーでパフォーマンス上の深刻な問題が発生し、それが原因でクライアント アプリケーションでタイムアウトが発生しているとします。一時的な問題であることも考えられます。実際、10 ～ 15 分でパフォーマンスは通常の状態に戻ります。
SQL Server のエラー ログをチェックしたところ、次のようなエラー メッセージが記録されていました。
"SQL Server プロセス メモリのかなりの部分がページ アウトされています。結果として、パフォーマンスが低下する可能性があります。継続時間: 300 秒。メモリ使用率: 34%。"
"IOCP リスナが応答しません。"
.gif "注意") 注意 |
|---|
IOCP は "IO 完了ポート" を表します。このポートは、ネットワーク経由のユーザー要求を処理します。このメッセージは、完了ポートが最後の 1 分間ブロックされていたことを示しています。 |
SQL Server の応答が鈍くなっていることから、サーバーがメモリ不足に陥っていることが考えられました。タスク マネージャでメモリを確認したところ、サーバーには十分すぎるほどの空きメモリ領域が存在しています。そこで、SQL Server Management Studio からデータベースに接続を試みましたが、タイムアウトが発生して接続に失敗しました。Windows のコマンド プロンプトから SQLCMD - A コマンドを使ってサーバーに接続することはできます。これにより、専用管理者接続上でセッションを開くことができます。
ここで拡張イベントを使って、より詳細な情報を取得するには、次のような拡張イベント セッションを作成します。
システム メモリ シグナルと合計サーバー メモリの変化に対するイベントを追加します。
出力を ETW に送ります。この出力は、ページ ファイルや SQL Server のデータベース ファイルとは別のドライブ上に作成されたファイルに書き込まれます。
Windows コマンド プロンプトで、すべてのメモリ イベントと Windows カーネル ETW トレースを有効にします。両方のトレースを数分間実行した後、拡張イベント セッションと Windows カーネル トレースを終了します。
tracerpt.exe を使用して、Windows トレースと SQL Server ETW トレースの両方を相互に関連付けます。システム メモリ不足の通知が設定されたことを示すイベントを探しましたが、該当するイベントは見つかりません。その代わりに、サーバー上のすべてのプロセスから、大量のページ エラーが報告されていることに気付きました。そこで、ページングの直前のイベントを調べたところ、ドライバからのメモリ割り当て要求に応答するために、すべてのプロセスの作業セットがトリミングされていることがわかりました。
過度に高い CPU 使用率のトラブルシューティング
実稼働システムで CPU 使用率が過度に上昇しているため、その原因を調べているとします。システム上で実行されたクエリに原因があるのかどうかを確認するため、各種の動的管理ビュー (DMV) を使って調査しました。その結果、ほとんどのクエリがアドホック ユーザー クエリであることがわかりました。DMV から取得した情報では、問題を十分に診断することはできません。
次のような拡張イベント セッションを作成します。
ステートメントの完了に対するイベントを有効にし、その際、述語で CPU のしきい値を指定します。
イベントの発生時にクエリ プランだけを収集するアクションを割り当てます。
収集されたすべてのデータをファイルに書き込みます。このファイルは、ログやデータベース ファイルとは別のドライブに置きます。
拡張イベント セッションを開始した後、出力結果を調査したところ、頻繁に結合される 2 つのテーブル間におけるデータ型の変換が、CPU の問題を引き起こしていることがわかりました。
デッドロックのトラブルシューティング
ユーザーから、特定のアプリケーションでデッドロック エラーが発生するとの報告を受けました。できるだけ効率よく問題を解決するために、発生頻度の最も高いデッドロックに的を絞って調査することにしました。次のような拡張イベント セッションを作成します。
セッションに対してデッドロック イベントの追跡を構成します。
デッドロックの識別子に基づいて集計を行うターゲットを指定します。
拡張イベント セッションを実行した後、新たにデッドロックが報告されたら、各ソースに対応する詳細な XML デッドロック グラフと共に、集計したデッドロック情報を取得できます。この情報を使用することにより、発生頻度の最も高いデッドロックを特定し、問題の解決に着手できます。
要求アクティビティと Windows ETW ログとの関連付け
実稼働サーバーでアプリケーションの処理速度が低下する問題が発生しています。原因を調査したところ、ディスクの読み取りに時間がかかっていることまでは判明しました。次のような拡張イベント セッションを作成します。
ディスクの読み取りをセッション イベントとして追加します。
収集されたデータを ETW に送信します。
拡張イベント セッションを開始した後、Windows ETW カーネル トレースを実行します。10 分が経過したら、両方のセッションを停止します。
tracerpt.exe を使用して、Windows トレースと SQL ETW トレースをマージします。このマージしたトレース結果を基に、SQL Server から Windows カーネルへの読み取り要求を相互に関連付けて追跡できます。分析結果は、I/O 要求が SQL Server に返されるまでの間に大きな遅延が生じていることを示しています。この情報を使用することにより、物理的な I/O パスに入出力の問題が存在するという結論を得ることができます。