0

私が継承したコードには、特定の SelectParameters に対して常にタイムアウトするかなり複雑な select ステートメントを持つ SqlDataSource があります(「タイムアウトの期限が切れました。操作が完了する前にタイムアウト期間が経過したか、サーバーが応答していません。」)。

管理スタジオで同じパラメーターを使用してまったく同じクエリを実行すると、クエリがタイムアウトすることはなく、常に 1 秒もかかりません。

ここで何が問題なのか、誰にも分かりますか？意味がわかりません。

4

3 に答える 3

2

暗闇の中でのショット: パラメータは実際には同じではありません。SSMS ではクエリの ASCII パラメータを渡しますが、ADO.Net では Unicode パラメータを渡します。SqlCommand.Parameters.AddWithValue("@myParam", myValue)が文字列の場合、型 NVARCHAR のパラメーターを追加しますmyValue。SQL の変換規則によりSELECT ... FROM ... WHERE myField = @myParam、myField が Ascii (VARCHAR) で @myParam が Unicode (NVARCHAR) の場合、実行ではテーブル スキャンを実行する必要があり、myField でインデックスを使用できないため、SSMS 実行と比較するとパフォーマンスが大幅に低下します。 .

先に述べたように、これは暗闇でのショットにすぎませんが、一般的な落とし穴であり、デバッグするのはかなり微妙です。

于 2009-10-14T21:05:31.570 に答える
1

人々がデータベースで作業を行っている場合、選択はトランザクションが完了するまで待機する可能性があります。タイムアウトは、データベース内の他のトランザクションに応じて、ヒットまたはミスします。

Management Studio で を実行SET SHOWPLAN_ALL ONしてから、クエリを実行します。出力で「SCAN」を探します。テーブルまたはインデックス スキャンがある場合は、ロック/ブロックの犠牲者になる可能性が高くなります。インデックス/テーブル全体を処理する必要があり、行をロックしている人がいると待機する必要があるためです。

アプリケーションを実行し、画面が更新されない場合は、管理スタジオでこれをすばやく実行します。

EXEC sp_lock

現在進行中のロックに関する基本的な情報が表示されます。

于 2009-10-14T20:48:31.870 に答える
0

以下を試してみてください。おそらくこれにより、何が起こっているのかが明確になります。

  1. SQL プロファイラーで、複雑な SQL ステートメントが変換された正確なステートメントをキャプチャし、Viual Studio で実行します。

  2. 問題の sql ステートメントが実行されている場合は、管理スタジオでアクティビティ モニターを確認してください。SQLをブロックしている可能性のあるものを知ることができます。

  3. 他に何が同時に実行されているかを確認することが重要です。アプリケーションはマルチスレッドですか? 使用後すぐに SQL 接続がクローズ/破棄されていますか (そうでない場合、タイムリーにクローズされない可能性があります)。複数のスレッドで同じSQL接続が使用されていますか?

于 2009-10-14T21:06:53.923 に答える