SQL Server 2008 Std Editionのインストールでパフォーマンスモニターを追跡しているときに、SQLコンパイル/秒が5秒ごとに3から約50に急上昇することに気付きました。
また、バッチリクエスト/秒に対するコンパイルの比率も比較的高くなっています。これは理想的には1/10の比率である必要があることを理解していますが、私たちは8/10のように取り組んでいます。
dbは、多数のアプリケーションを備えたビジーなWebサイトをサポートしているため、過剰なコンパイルの原因、特に5秒のスパイクを特定するのは困難です。ほぼすべてのクエリは、埋め込みSQLではなくストアドプロシージャ呼び出しであり、かなりの（48GB）RAMがあります。
特定の時点で、現在コンパイル中のクエリを確認する方法はありますか？もしそうなら、問題があるかどうかを解決することができます。
過去にプランのキャッシュ/過剰なクエリの再コンパイルに関する問題を調査する必要があったときは、Microsoftのホワイトペーパー「SQLServer2008でのプランのキャッシュ」</a>で提供されているガイダンスに従っていました。プランのキャッシュ、クエリプランの再利用、再コンパイルの原因、再コンパイルの特定、およびその他の関連トピックについて説明します。
そうは言っても、SQL Serverプロファイラー（クライアントツールのインストールの一部としてインストールした場合は、Microsoft SQL Server 2008->パフォーマンスツールの下にあるはずです）は、クエリのコンパイルに直接関連する3つのイベントを公開します。
ストアドプロシージャを使用しているため、 SP：Recompileイベントについてのみ心配する必要がある可能性があります。このイベントは、ストアドプロシージャ、トリガー、またはユーザー定義関数が再コンパイルされるたびに発生します。TextData列には、ステートメントの再コンパイルを引き起こしたtsqlステートメントのテキストが表示され、EventSubClass列には、再コンパイルの理由を示すコードが表示されます。
SPのEventSubClassコード：SQL2008での再コンパイル
次の5つのイベントを監視すると、SQL Serverで呼び出されているストアドプロシージャとステートメント、および再コンパイルをトリガーしているものを確認できます。
また、通常、これらのイベントのすべての列をキャプチャするようにプロファイラートレースを設定します。これらの5つのイベントを使用してトレースを設定し、30〜60秒間トレースを実行してから一時停止すると、再コンパイルの原因のスナップショットが得られるはずです。
ノイズが多すぎる場合は、トレースプロパティに列フィルターを追加して、イン/アウトイベントをフィルター処理することができます。たとえば、ほとんどの再コンパイルが1回限りのデータベースで行われている場合は、databaseIDまたはdatabaseName列に列フィルターを設定して、そのデータベースに対して実行されるクエリだけがトレースに含まれるようにします。
次に、クエリが再コンパイルされているパターンを探し始め、Microsoftのホワイトペーパーを使用して、クエリが再コンパイルをトリガーする理由を説明します。