5

21 行のデータ (4 列) が取り込まれている SqlDataAdapter があります。それを駆動する sproc は、SQL Mgmt Studio では数秒で返されますが、.Fill() には 5 分かかります。

    ArrayList ret = new ArrayList();
    SqlDataAdapter da = null;
    SqlCommand cmd = null;  
        cmd = base.GetStoredProc("usp_dsp_Stuff"); //Returns immediately in MSSMS.
        cmd.CommandTimeout = 3600; // Set to 6 min - debug only
        base.AddParameter(ref cmd, "@Param1", ParameterDirection.Input, SqlDbType.BigInt, 8, 19, 0, theParam1);
        base.AddParameter(ref cmd, "@Param2", ParameterDirection.Input, SqlDbType.BigInt, 8, 19, 0, theParam2);
        base.AddParameter(ref cmd, "@Param3", ParameterDirection.Input, SqlDbType.Char, 1, 'C');
        da = new SqlDataAdapter(cmd);
        DataTable dt = new DataTable();
        da.Fill(dt); //Takes 5 minutes.

何か案は？

前もって感謝します！-クリス

4

8 に答える 8

4

お手伝いありがとう。これに対する解決策は、sproc が使用していた結合に with (nolock) ステートメントを追加することでした。

from category_tbl c INNER JOIN dbo.categoryItem_LNK cl WITH (NOLOCK) ON c.categoryid = cl.categoryid

SqlDataAdapter を使用した場合にのみ劣化が見られた理由はわかりませんが、この変更により問題はすぐに解決されました。

ありがとう、クリス

于 2009-04-20T18:40:23.473 に答える
3

私はこれが遅すぎることを知っています.7年遅すぎるように! しかし、今日この問題に遭遇したので、私の修正を共有したいと思いました。私のインスタンスでは、SQL から取得されたデータはテーブル値関数でした。テーブル値関数は約 3500 行しか返さず、1 秒もかかりませんでしたが、C# コードの Fill() でタイムアウトしました。誰がどのように機能するかはわかりませんが、関数を削除して再作成すると修正されました。レポートで使用された後に変更を加えた場合にビューを再作成する必要があるように、.NETがSQLによって与えられたデータを読み取る方法に関係していると思います。繰り返しますが、舞台裏で何が起こっているのか100％確信はありませんが、私にとっては簡単な修正でした

于 2017-02-17T11:20:01.397 に答える
1

不適切なクエリ プランとパラメーター スニッフィング。ストアド プロシージャの場合、特にパラメーターによって読み取り行が大幅に調整される場合、受信パラメーターを参照することによる不適切な実行計画が原因です。SET パラメータが異なるため、SQL Management Studio では発生しません。

このスレッドはあなたの問題をうまくまとめています: http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/9fd72536-f714-422a-b4c9-078e2ef365da/

これは、パラメータ スニッフィングの典型的なケースです。ほとんどの場合、アプリケーションはさまざまな SET オプション (クライアント API によって設定) で実行され、SSMS で作成されたものとは異なる実行プランを使用します。何が起こるかというと、アプリケーションを介して初めてプロシージャが呼び出されたときに、渡されたパラメータに基づいて実行計画が作成されます。ただし、この実行計画は別のパラメータ セットには適していない可能性があり、別のパラメータ セットで実行するとパフォーマンスが低下する可能性があります。詳細とさまざまな解決策については、次を参照してください。 http://pratchev.blogspot.com/2007/08/parameter-sniffing.html

プランのキャッシュとクエリ プランの再利用の内部の詳細については、
http ://technet.microsoft.com/en-us/library/cc966425.aspx を参照してください。

于 2010-02-03T15:53:55.047 に答える
1

ニュースを壊すのは嫌いですが、(NOLOCK) は解決策ではありません。ダーティ リード、データの欠落/重複、さらにはクエリの中止など、新しい問題が発生するだけです。SQL データベースのロックはあなたの味方です。

ロック (またはさらに悪いことにブロック) が原因で速度が低下している場合は、SSMS を介して実行されている接続オプションと、アプリケーションで使用されている接続オプションを比較します。SQL プロファイラーを使用して、コードがどのように実行されているかを確認します。

これらのフィールドのいずれかが大きなオブジェクトである場合、SSMS は既定で数百文字のみを自動的に取得することに注意してください。返された余分なデータが要因である可能性があります。

于 2009-04-22T19:03:47.533 に答える