これは私がいくつかまともな回答を得た別のフォーラムで尋ねた質問ですが、ここに誰かがもっと洞察力を持っているかどうかを見たいと思っていました。クエリはWebアプリケーションからタイムアウトしますが、管理スタジオからうまく実行されます
問題は、Webアプリケーションのページの1つがストアドプロシージャ呼び出しに達したときにタイムアウトするため、Sqlプロファイラまたはアプリケーショントレースログを使用してクエリを検索し、それがなぜ遅いのかを理解するために管理スタジオにしかし、あなたはそこからそれを走らせて、それはちょうど一気に進み、毎回戻ってきません。
私の特定のケースでは、ASP.NET 2.0とSql Server 2005を使用していましたが、問題はどのRDBMSシステムにも当てはまると思います。
これは私がこれまでの私の研究から学んだことです。
.NETは管理スタジオにログインしたときと同じ接続設定で送信します。ここでは、SQLプロファイラとの接続を盗聴場合は見るものである。
-- 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 Serverにログインしたときに、私は今の設定が同じであることを確認するために、私は実行するすべてのクエリ上で設定したものを貼り付けています。
このケースでは、切断して再接続した後に個々の設定を試したところ、arithabortをoffからonに変更すると問題のクエリが90秒から1秒に短縮されました。
最も可能性の高い説明は、SQL Serverが最も効果的なクエリプランであると考えるものを選択するために使用する、パラメータスニッフィングに関するものです。接続設定の1つを変更すると、クエリオプティマイザが別のプランを選択する可能性があります。この場合、不正なプランが選択されている可能性があります。
しかし、私はこれを完全には確信していません。私はこの設定を変更した後に実際のクエリプランを比較しようとしましたが、diffが変更を表示するのをまだ見ていません。
場合によってはクエリが遅く実行される可能性のあるarithabort設定について他に何かありますか？
解決策は単純だったようです。set arithabortをストアドプロシージャの一番上に置くだけです。しかし、これは逆の問題につながる可能性があります。クエリパラメータを変更すると、突然、 'on'よりも 'off'で速く実行されます。
当面は、 'with recompile'プロシージャを実行して、毎回計画が再生成されることを確認しています。この特定のレポートでは、再コンパイルするのに1秒かかることがあるため、これは大丈夫です。レポートにはそれほど目立たないので、戻ってくるのに1〜10秒かかります（それはモンスターです）。
しかし、頻繁に実行され、できるだけ早く数ミリ秒で復帰する必要がある他のクエリではオプションではありません。
+1 SQLプロファイラからこれらの設定を取得し、それらをManagement Studioに貼り付けることは素晴らしいヒントです。 –
+1 SET ARITHABORT OFFは、以前にタイムアウトしたクエリを美しく開始するのに十分でした。 – Spud
@ eric-z-beardこれらの値はどこに入れていますか？ SPの内部またはEXECの前にsp_whatever from .NET – djandreski
は、SelectCommandがタイムアウト値を変更してみてください：
DataAdapter.SelectCommand.CommandTimeout = 120;
解決策ではありません！回避策です！ – Icet
テストこのうちステージングボックスの最初の、SQL Serverのサーバーレベルでそれを変更
宣言@option int型
セット@option = @@オプション| 64
幹部ます。sp_configure 'ユーザーオプション'、 @option
RECONFIGURE
あなたはまだトレースASP.NETをオンにしていますか？ SQLストアドプロシージャ自体が問題ではないインスタンスがありました。プロシージャが5000行を返し、アプリケーションが問題の原因となっていた5000アイテムでデータバインドされたListItemsを作成しようとしていたという事実がありました。
ウェブアプリ機能間の実行時間をトレースすることで、トレースを利用してトラッキングすることができます。
sp_who2コマンドを使用して、問題のプロセスが何であるかを調べることができます。これは、別のプロセスによってブロックされている場合、またはCPUやIO時間が過度に多くなった場合に表示されます。
私はSQLレポートサービスで同じ問題がありました。 変数のタイプをチェックしようとしました。 私は、varcharをどこに送るかのように、異なるタイプの変数をSQLに送信していました。 は整数でなければなりません。 Reporting Servicesの変数とSQLのストアドプロシージャの変数の型を同期した後、私はこの問題を解決しました。
私は同様の問題を抱えています。 sproc createで "WITH RECOMPILE"オプションを設定して、呼び出されるたびに実行計画を再計算するようにしてください。時には、クエリ・プロセッサが分岐ステートメントまたはケース・ステートメントを多数含む複雑なストアド・プロシージャで混乱し、本当に最適でない実行プランを取得することがあります。それが問題を「修正」しているようであれば、統計情報が最新であることを確認したり、sprocを分解したりする必要があります。
また、sprocのプロファイリングによってこれを確認することもできます。 SQL Managment Studioから実行すると、IOはASP.NETアプリケーションからプロファイルを作成するときとどのように比較されますか。彼らが非常に多くの場合、それは悪い実行計画を引き出すことを再実施するだけです。
私たちは同じ問題を抱えており、ここで私たちが知ったことがあります。
データベースのログサイズはデフォルト（814 MB）に維持され、自動拡張は10％でした。 サーバーでは、最大サーバーメモリも既定の設定（2147483647 MB）に保持されていました。
私たちのログがいっぱいになり、成長が必要になったとき、サーバーからのすべてのメモリを使いました。実行するコードは残っていませんのでタイムアウトしました。私たちがやったことは、データベースログファイルの初期サイズを1 MBに、最大サーバーメモリを2048 MBに設定したことです。これはすぐに私たちの問題を解決しました。もちろん、これらの2つのプロパティを必要に応じて変更できますが、これはコードでストアドプロシージャを実行するときにタイムアウトの問題に遭遇した人にとっては理想的ですが、SSMSで超高速で実行されます。
私は同じ問題があり、http://stackoverflow.com/questions/250713/sqldataadapter-fill-method-slowが私の問題を解決しました – David