2

データ コンテキストで SubmitChanges() を呼び出すと、次の例外で継続的な問題が発生しました。

「タイムアウトの期限が切れました。操作が完了する前にタイムアウト期間が経過したか、サーバーが応答していません。ステートメントは終了しました。」

これは、5 ～ 100 人の同時ユーザーが使用している ASP.NET Web アプリケーションで発生しています。サイト/データベースのタイムアウト期間を長くしても効果はなく、実行中のクエリは非常に単純で高速であることに注意してください。エラーが発生したときにサイトが無期限にハングする原因となるタイムアウト期間を完全に削除するところまで行きました。

この問題のその他の側面:

  • 断続的であり、確実に再現することはできません
  • いくつかの異なる方法でのみ発生し、他の方法では発生しません
  • タイムアウト期間を増やしたり削除したりしても効果がない
  • サーバーを再起動して MSSQL データベースを再起動しても解決しない

これは同時実行/デッドロックの問題のようですが、デバッグまたは修正する方法がわかりません。何か案は？

4

1 に答える 1

1

データベース操作がアプリケーションによって実行され、SubmitChanges の応答を待っているときに、Sqlserver で次のクエリを実行してみてください

**sp_who2**

返された出力の Blkby 列を見てください。何らかの値を持つ行が 1 つ見つかった場合 (これは、接続をブロックしているコマンドの SPID です)。

その列の ProgramName をチェックして、詳細情報を見つけてください。

説明に従ってブロックしている SPID が見つかった場合は、次のコマンドを実行して、その SPID で最後に実行されたクエリを見つけます。Blkby の値が 59 であるとします。

**dbcc inputbuffer(59)**

これにより、アプリケーション クエリをブロックするクエリが得られます。

これは、トラブルシューティングの 1 つの方法です。

ストアド プロシージャのデフォルト値のパラメータが原因でタイムアウトが発生し、パラメータ スニッフィングが発生することがあります。

その場合、使用する手順の最初の行としてその行を使用してみることができます

アリサボートをオンに設定

手順を変更して、データベース操作を再試行してください。

機能する場合は、後でこの行を削除してから、手順を再度変更してください。

うまくいく場合は、これを試してください。

ここで同様の質問を見つけました

また、クエリの実行速度が Web アプリで遅く、SSMS ですぐに実行される場合の詳細については、こちらを参照してください。

Web から呼び出すとストアド プロシージャが遅くなり、Management Studio からは高速になる

それが役に立てば幸い。

于 2012-06-30T16:14:18.893 に答える