4
SQL Server 2008 R2でSQL Serverステートメントが断続的に遅くなる
あるお客様では、アプリケーションのパフォーマンスに問題があります。SQL Serverデータベースのデータを消費および更新する.NET 3.5 Webアプリです。現在、本番環境は、フロントエンドとしてのWindows 2008 R2マシンと、バックエンド上のSQL Server 2008 R2クラスターで構成されています。このアプリは、COM +とMSDTCを使用してデータベースに接続します。 ここで何が起こっているのか:エンドユーザーは、アプリケーションの速度が遅いと不満を言うことがあります。一部のページは、予想よりもロードに時間がかかります。何が起こっているのかを理解しようと試みているうちに、パフォーマンスの低下の原因となる可能性のあるデータベース側での奇妙な動作を見つけることができました。予想されることを実行するのにより多くの時間がかかるSQLステートメントが時々あることに気付きました。プロファイラートレース(TSQL_Durationテンプレートを使用)を使用して実行時間の長いクエリを特定し、これらのステートメント(主にアプリケーションのストアドプロシージャの呼び出し)の一部を特定しました。 問題は、これらのストアドプロシージャをSQL Management Studioのデータベースで直接実行すると、時間がかかる(約7/8秒)こともあれば、高速(1秒未満)になることもあります。SQLマシン(4コア、32 GB)が他のアプリケーションで使用されておらず、これらのクエリの実行にこれほど時間がかからないため、これがなぜ起こるのかわかりません。 DBAやSQL Serverの第一人者ではない私は、問題を理解するのに役立つかもしれないものを調べようとしてきました。以下は、問題を解決しようとするためにとったステップと、これまでに発見したことです。 アプリケーションによって呼び出されるすべてのTSQLコードは、ストアドプロシージャで記述されます。 SQL Serverプロファイラーで長時間実行されるクエリの一部を特定しましたが、Management Studioで実行すると、実行に時間がかかる(4〜10秒)か、迅速に実行(1秒未満)します。パラメーターに渡された同じデータを使用して、まったく同じクエリを実行しています。これらのクエリは、主に選択ステートメントを含むストアドプロシージャです。 待機およびキューの統計を調べて、いくつかのリソースで待機しているプロセスがあるかどうかを確認しようとしました。次のクエリを実行しました。 WITH Waits AS (SELECT wait_type, wait_time_ms / 1000.0 AS WaitS, (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS, signal_wait_time_ms / 1000.0 AS SignalS, waiting_tasks_count AS WaitCount, 100.0 * wait_time_ms …