[解決済み] ストアドプロシージャをウェブから呼び出すと遅く、Management Studioから呼び出すと速い

質問

Web アプリケーションから呼び出されるたびに、非常識なほどタイムアウトするストアド プロシージャがあります。

Sql Profiler を起動し、タイムアウトする呼び出しをトレースして、最終的に以下のことを発見しました。

1. MS SQL Management Studio 内から同じ引数でステートメントを実行した場合 (実際、私は sql プロファイル トレースからプロシージャ呼び出しをコピーし、それを実行しました)。平均で 5 ～ 6 秒で終了します。
2. しかし、Web アプリケーションから呼び出された場合、30 秒以上 (トレースにおいて) かかるので、私の Web ページはそれまでに実際にタイムアウトしてしまいます。

私の Web アプリケーションが独自のユーザーを持っているという事実を除けば、すべてのことは同じです (同じデータベース、接続、サーバーなど)。 私はまた、Web アプリケーションのユーザーでスタジオで直接クエリを実行してみましたが、6 秒以上かかりませんでした。

どのようにしたら、何が起こっているのかを見つけることができますか？

トレースでは、遅延が実際のプロシージャにあることが明らかなので、BLL > DAL レイヤーやテーブル アダプタを使用していることとは関係ないものと推測しています。考えられるのはそれだけです。

EDIT でわかったのですが このリンク で、ADO.NET が ARITHABORT を true に設定します。これはほとんどの場合良いことですが、時々この現象が発生します。 with recompile オプションを追加することです。私の場合、それはうまくいきませんが、これに非常に類似した何かだと思われます。どなたかADO.NETが他に何をするのか、またはどこでその仕様を見つけることができるかをご存知ですか？

どのように解決するのですか？

過去に同じような問題が発生したことがあるので、この質問の解決策を見たいと思っています。OP に対する Aaron Bertrand のコメントにより、次のようになりました。 Web から実行するとクエリがタイムアウトするが、SSMS から実行すると超高速になる であり、質問は重複していませんが、その回答はあなたの状況に非常によく当てはまるかもしれません。

本質的には、SQL Server に破損したキャッシュ実行プランがあるように思われます。Web サーバーで不良プランをヒットしていますが、SSMS は ARITHABORT フラグに異なる設定があるため、異なるプランに着陸します (それ以外は、特定のクエリ/ストアド プロックに影響を与えないでしょう)。

参照 ADO.NET コール T-SQL ストアド プロシージャが SqlTimeoutException を発生させる を参照してください。