プロファイラは、SQL Server に対して実行されたすべての SQL 文を監視／記録できる非常に強力なツールです。

図1：プロファイラで SQL 文を監視しているところ

　プロファイラは、SQL 文のほかにも、デッドロックを監視したり、ログインの成功／失敗を監視したり、いろいろな情報を監視／記録できるので、次のように多くの場面で利用できます。

1. パフォーマンス チューニング ツールと して利用
2. 監査証跡（Audit Trail） ツールと して利用
3. アプリケーション開発時のデバッグ ツールと して利用
4. Enterprise Manager やクエリ アナライザ、プロファイラ自身など、
   GUI ツールの内部動作を調べたい場合に利用
5. レプリケーションやログ配布といったウィザードによってブラック
   ボックス化されている機能の内部動作を調べたい場合に利用

　4つ目／5つ目は、ほとんどの方が関係ないかもしれませんが、最初の 3つに関しては非常に便利なので、ぜひ活用してほしいと思います。

　プロファイラは、「実行に時間がかかっている SQL」や「ロック待ちの原因となっている SQL」「デッドロックの原因となっている SQL」「ロック エスカレーションの原因となっている SQL」などを簡単に調べることができるので、パフォーマンス チューニング  ツールとして大変役立ちます。

図2：デッドロックの原因となっている SQL を監視しているところ

　そのほか、「統計の自動更新が発生したタイミング」や「データファイル／ログファイルが自動拡張したタイミング」「メモリ  ソートできずにディスク  ソートが行われたとき」「プロシージャ キャッシュが利用されたとき」なども監視できます。パフォーマンス  チューニング時には、システムモニタとともに欠かせないツールとなるので、ぜひ活用してほしいと思います（システムモニタについては第4回で説明します）。

　プロファイラは、「いつ」「誰が」「どのアプリケーションからログインして」「どんな SQL 文を実行したのか」を記録できるので、不正侵入や不正操作を監視／記録するためのツール、いわゆる「監査証跡」ツールとしても利用できます。例えば、「ログインの失敗」を監視することで、辞書攻撃（ディクショナリ アタック）を検出したり、“顧客マスタ”テーブルへの SELECT 文の実行履歴を記録することで、顧客情報の漏えいを監視するといった使い方ができます（この具体的な操作手順については次回説明します。プロファイラと同等の操作を Transact-SQL を使ってコマンドレベルで制御できます）。

　プロファイラは、データベース アプリケーション開発時のデバッグ用途としても大変役立ちます。アプリケーション  エラーが発生したときに、コードの文法的なミスなのか、SQL Server が発生させているエラーなのか、原因が分かりづらいときにプロファイラを利用すると便利です。次のコード（VB.NET／ADO.NET）を例に見ていきましょう。

　このコードは、ストアドプロシージャ「procTest」を実行しようとしていますが、実行時に次のアプリケーション  エラーが発生したとします。

図3：エラー 「@p1 はプロシージャ procTest の引数ではありません」

　しかし、エラーを見ただけでは、どういう意味のエラーなのかが分かりづらいかと思います。このような場合には、プロファイラを起動して、もう一度アプリケーション エラーを発生させます。すると、SQL Server に対して実行された SQL（Transact-SQL）が分かります。

図4：エラーが発生したときの SQL を記録する

　次に、この記録した SQL をクエリ アナライザへ貼り付けて実行します。

図5：プロファイラで記録した SQL をクエリ アナライザから実行してみる

　すると、図3のエラーと同じエラーが発生することが分かり、エラーは SQL Server が発生している（SQL の記述に問題がある）ということが分かります（procTest のパラメータは“@param1”と定義していて、「exec procTest @param1=1」と実行させる ⇒ cmd.Parameters.Add("@param1"･･･ とするのが正しい動作）。

　また、プロファイラを使えば、ログインの成功を意味する「Audit Login」や「sp_reset_connection」が記録されない場合は、コードから SQL Server へ接続が失敗していることが分かります。この場合、SQL Server 名の間違いや認証エラー、SqlConnection クラスの Open メソッドの記述し忘れなどが考えられます。なお、接続プール内の接続を再利用して SQL Server へ接続する場合は、Audit Login は記録されずに、sp_reset_connection のみが記録されます。sp_reset_connection は、接続プール内の接続を初期化するためのものです。

　また、接続が成功した後に SQL 文が記録されない場合はコードが文法的に間違っている可能性があります。このように、プロファイラを使えばアプリケーション開発時のデバッグ ツールとして利用できるので、ぜひ活用してほしいと思います。

　ここからは、実際のプロファイラの基本的な操作方法を説明します。まず、プロファイラを起動するには、「スタート」メニューの「すべてのプログラ ム」→ 「Microsoft SQL Server」から「プロファイラ」をクリックします。

　次に「ファイル」メニューの「新規追加」→「トレース」とクリックします。すると、次のようにプロファイラで監視対象としたい SQL Server を指定するためのダイアログが表示されます。

図6：接続先（監視対象）となる SQL Server の指定

　ここで、接続先となる SQL Server の名前を入力し、「OK」ボタンをクリックします。すると、次のように「トレース プロパティ」ダイアログが表示され、どういった情報を監視するのかや、トレース結果をファイルとして保存するのかなどを設定できます。

図7：「トレース プロパティ」ダイアログ

　ここでは、とりあえず何も設定せずに「実行」ボタンをクリックします。すると、次のようにトレース（記録）が始まります。

図8：トレース中の様子

　クエリ アナライザや開発中のアプリケーションなどを起動して、SQL Server に対して任意の SQL 文を実行してみてください。「SQL:BatchCompleted」や「Audit Login」などが記録されていくことを確認できると思います。SQL:BatchCompleted は、バッチが完了したときに記録され、Audit Login はログインが成功したときに記録されます。したがって、SQL:BatchCompleted に表示される SQL 文を参照すれば、SQL Server に対してどういった SQL 文が実行されているのかを確認できます（ストアドプロシージャの場合は、RPC:Completed に表示されるものを参照します）。

　また、次のように結果を右にスクロールすると、Duration（実行にかかった時間：ミリ秒単位）や、CPU（実行時の CPU 利用時間）、Reads（読み取った I/O 数：ページ単位）、SPID（プロセスID）、StartTime（開始時間）なども確認できます。

図9：結果を右にスクロールすると、Duration（実行時間） や StartTime（開始時間）などを確認できる

　プロファイラの動作をなんとなく確認できたら、一度トレースを停止しておきましょう。トレースを停止するには、次のようにツールバーの「停止」ボタンをク リックします。

図10：トレースの停止

　トレースの停止後、「ファイル」メニューの「名前を付けて保存」→「トレース ファイル」をクリックすると、トレース結果をファイルとして保存できます（拡張子は .trc）。

図11：トレースの保存

　保存したトレース ファイルは、「ファイル」メニューの「開く」→「トレース ファイル」をクリックして、後から参照できます。また、このようにしてファイル（.trc）を開いた場合は、「再生」メニューを使って、記録した SQL 文を再度実行させることもできます（ステップ実行やブレークポイントの設定も可能）。

図12：トレースの再生（記録した SQL 文の再実行が可能）

　また、開いたトレース ファイルに対して「名前を付けて保存」→「トレース テーブル」とクリックすれば、SQL Server 上のテーブルとして保存することもでき、次のように SELECT 文を使ってトレース結果を操作できるようになります。これはトレース結果をグラフィカルに表示するアプリケーションを作成したい場合に便利です。

図13：トレース結果をテーブルへ保存すれば SQL で参照可能

　前出の図7の「トレース プロパティ」ダイアログでは、何も設定せずに「実行」ボタンをクリックしましたが、このダイアログでは監視対象を増やしたり、フィルタの設定などを行なうことができます。

　プロファイラでは、トレース（記録）したいイベントのことを「イベントクラス」（EventClass）といい、「イベント」タブで設定します。

図14：「イベント」タブでイベントクラスを追加／削除

　このタブで追加したイベントクラスは、そのイベントが発生したときにそのことを記録します。例えば、「SQL:BatchCompleted」イ ベント クラスは、バッチが完了したときに記録され、「SQL:BatchStarting」イベントクラスは、バッチが“開始”されたときに記録されるといった 具合です。そのほかの主なイベントクラスは次のとおりです。

　イベントクラスについての詳細は、Books Online の以下の場所が参考になります。

図15：イベントクラスのヘルプ（Books Online）

　「データ列」タブは、イベントが発生したときの周辺情報をどの順番で表示するのかや、何を記録（表示）するのかを設定することができます。

図16：「列」に列挙した順番に左から表示される （ デフォルトは EventClass、TextData、ApplicationName、 NTUserName、LoginUserName、CPU、 Reads、･･･ ）

　追加できるデータ列には、HostName（マシン名）、DatabaseID（データベースID）、ObjectID（オブジェクトID）など があり ます。ただし、イベントクラスによっては記録できないデータ列もあります。例えば、SQL:BatchStarting イベントクラスは、バッチの開始時に記録されるものなので、Duration（実行にかかった時間）は関係ないため記録されません。こういった情報（イベントクラスとデータ列の関係）は、Books Online で次のように確認できます。

図17：イベントクラスとデータ列の関係。 ■ が記録可能なデータ列

　「フィルタ」タブでは、記録するイベントをフィルタ（制限）することができます。プロファイラで多くのイベントをトレースすることは、それだけ SQL Server へ負荷をかけることになるので、本番環境（パフォーマンス  チューニング時など）では、できる限りフィルタを設定するようにします。

図18：記録するイベントのフィルタ（制限）

　フィルタは、「データ列」タブで追加した項目に対して、「Equals（等しい）」「Like（文字列のワイルドカード指定）」「Grater than or equal（以上）」「Less than or equal（以下）」などを指定することができます。例えば、デフォルトでは、ApplicationName（アプリケーション名）データ列に対して 「Not Like SQL Profiler」というフィルタが設定され、プロファイラ自身が発行した SQL を記録しないようにしています。また、図18では Duration（実行にかかった時間）に「Grater than or equal 3000」と設定することで、3秒（3000ミリ秒）以上実行に時間がかかったもののみを記録するようにフィルタしてします。

　「イベント」タブや「データ列」タブ、「フィルタ」タブで設定した情報は、“トレース テンプレート”という形で保存できます。次のように「ファイル」メニューの「名前を付けて保存」→「トレース テンプレート」をクリックし、任意のファイル名を入力すれば完了です。

図19：トレース テンプレートとして保存

　保存したテンプレートは、トレースの開始時に「全般」タブから選択できるようになります。

図20：トレース テンプレートの選択。「SQLProfilerStandard」（デフォルト）や 「SQLProfilerTSQL」テンプレートは、あらかじめ用意されたテンプレート。

　今回は、プロファイラの基本的な操作方法について説明しました。次回は、プロファイラをバックグラウンドで実行させる方法（トレースを Transact-SQL から実行する方法）を説明します。