これは私が別のフォーラムで尋ねた質問で、まともな回答が得られましたが、ここに誰かもっと洞察があるかどうかを知りたいと思いました.
問題は、Web アプリケーションのページの 1 つがストアド プロシージャの呼び出しに達したときにタイムアウトになることです。そのため、Sql Profiler またはアプリケーション トレース ログを使用してクエリを見つけ、それを Management Studio に貼り付けて把握します。なぜそれが遅いのか。しかし、そこから実行すると、毎回 1 秒もかからずに戻ってきます。
私の場合は ASP.NET 2.0 と Sql Server 2005 を使用していましたが、この問題はどの RDBMS システムにも当てはまると思います。
これは、私がこれまでの研究から学んだことです。
.NET は、management studio にログインしたときに得られるものとは異なる接続設定を送信します。Sql Profiler で接続をスニッフィングすると、次のように表示されます。
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
設定が同じであることを確認するために、SQLサーバーにログインしたときに実行するすべてのクエリの上にこれらの設定を貼り付けています。
この場合、切断して再接続した後、各設定を個別に試してみたところ、arithabort をオフからオンに変更すると、問題のクエリが 90 秒から 1 秒に短縮されることがわかりました。
最も可能性の高い説明は、パラメータ スニッフィングに関連しています。これは、Sql Server が最も効果的なクエリ プランであると考えるものを選択するために使用する手法です。接続設定の 1 つを変更すると、クエリ オプティマイザーが別のプランを選択する可能性があります。この場合、明らかに不適切なプランが選択されます。
しかし、私はこれについて完全に確信しているわけではありません。この設定を変更した後、実際のクエリ プランを比較してみましたが、差分に変更が表示されていません。
場合によっては、クエリの実行が遅くなる可能性がある arithabort 設定について他に何かありますか?
解決策は簡単に思えました: set arithabort on をストアド プロシージャの先頭に置くだけです。しかし、これは逆の問題につながる可能性があります: クエリ パラメータを変更すると、突然、「オン」よりも「オフ」の方が速く実行されます。
とりあえず、計画が毎回再生成されるように、'with recompile' という手順を実行しています。この特定のレポートでは、再コンパイルにおそらく 1 秒かかるため問題ありません。これは、返されるのに 1 ～ 10 秒かかるレポート (モンスターです) ではあまり目立ちません。
しかし、これは、はるかに頻繁に実行され、わずか数ミリ秒でできるだけ早く返す必要がある他のクエリのオプションではありません。
同様の問題がありました。sproc create で with "WITH RECOMPILE" オプションを設定して、システムが呼び出されるたびに実行計画を強制的に再計算するようにしてください。クエリ プロセッサは、多数の分岐またはケース ステートメントを含む複雑なストアド プロシージャで混乱し、実際には最適ではない実行プランを引き出すことがあります。これで問題が「修正」されたと思われる場合は、おそらく統計が最新であることを確認するか、sproc を分解する必要があります。
これは、sproc をプロファイリングすることでも確認できます。SQL Managment Studio から実行した場合、ASP.NET アプリケーションからプロファイリングした場合と比較して IO はどうなりますか。それらが非常に多い場合、それは悪い実行計画を引っ張っていることを強化するだけです.
ASP.NET トレースを有効にしましたか? 問題が SQL ストアド プロシージャ自体ではなく、プロシージャが 5000 行を返し、アプリが問題の原因となった 5000 項目でデータバインドされた ListItems を作成しようとしたという事実がありました。
Web アプリ関数間の実行時間とトレースを調べて、追跡に役立てることができます。
SQL レポート サービスで発生したのと同じ問題。変数のタイプを確認してみてください。整数である必要がある場所にvarcharを送信するなど、異なるタイプの変数をSQLに送信していました。Reporting Service と SQL のストアド プロシージャで変数の型を同期した後、問題を解決しました。
最初にステージングボックスでこれをテストし、SQLサーバーのサーバーレベルで変更します
@option int を宣言する
set @option = @@options | 64
exec sp_configure 'ユーザー オプション', @option
再構成
sp_who2 コマンドを使用して、問題のプロセスがどのような処理を行っているかを確認できます。これにより、別のプロセスによってブロックされているか、CPU や io 時間を過剰に使用しているかどうかが表示されます。
SelectCommand タイムアウト値を変更してみてください。
DataAdapter.SelectCommand.CommandTimeout = 120;