4

DBに接続し、いくつかのストアドプロシージャを実行してデータを取得するプログラムがあります。

データベースはSQLServer2008であり、プログラムはローカルで実行されます。接続はTCP/IP経由ですが、共有メモリが有効になっています。また、接続文字列のタイムアウトは45秒に設定されています。

SQL Server Management Studioで実行すると、実行に0〜5秒かかります。コードを実行すると、ランダムにタイムアウトします。

テストを行うために、タイムアウトを45秒から数分に増やしました。また、ブロッキングの問題を破棄するために、ストアドプロシージャがデータのみを「選択」することを確認しました（挿入または更新ステートメントはありません）。そして、次のようなselectステートメントに対していくつかのテーブル修飾子を試しました：、、nolock.. readpast..

また、チェックsp_who2しdbcc opentran()たところ、何もブロックされていません...そして.NetのSPIDはですrunning command ...。.NetがDBの応答を待機している間の詳細については、SQL Server Management Studioを使用して、同じステートメント（ストアドプロシージャまたは選択）を問題なく実行できます。

何が起こっているのかについての提案はありますか？

4

3 に答える 3

5

接続文字列のタイムアウトは、ログインのタイムアウトにのみ影響します。コマンドのタイムアウトに達したようです。これを変更するには、CommandTimeout. デフォルト値は 30 秒で、推奨値は 0 (無限タイムアウト) です。

あなたの手順がランダムに遅い実行にヒットする理由については、アプリケーションで遅い、SSMS で速いを読むことから始めることをお勧めします。パフォーマンスの謎を理解する

ところで、クエリはブロックされていない可能性があります。実行にそれだけの時間がかかる別の計画を実行します。チェックlast_wait_typeインすると、IO 待機が明らかになる可能性があります (PAGEIOLATCH、 sys.dm_os_workerssys.dm_exec_requestsジョインの下に赤いヘリング CXPACKET を追い詰めた後...)。しかし、私が最初にリンクした Erland Sommarskog による、はるかに包括的で優れた記事を繰り返しても意味がありません。

于 2012-11-09T15:37:38.983 に答える
0

タイムアウトが.net側からの場合は、この2つのパラメーターを接続文字列に追加します。

タイムアウト=3600000;

最大プールサイズ=360000;

于 2012-12-07T10:49:58.150 に答える
0

タイムアウトには、接続とクエリの 2 種類があります。

クエリがタイムアウトした場合、それはクエリの問題です。しかし、あなたはSQLサーバー管理スタジオを介して実行できると言っているので、クエリであるとは思えません。

接続がタイムアウトする場合は、ネットワークの問題である可能性が高くなります。実験 (ロック、ヒントなど) を行っているようですが、問題の原因はクエリであると想定しています。ネットワークの観点から考えてみてください。接続中のネットワークの問題を検出するのに役立つ SQL サーバーのアクティビティ モニターについて聞いたことがあります。

于 2012-11-09T15:48:23.727 に答える