2009-04-20 390 views
3

私は、21行のデータ(4列)で構成されているSqlDataAdapterを持っています。それを駆動するsprocはSQL Mgmt Studioで数秒で復帰しますが、.Fill()には5分かかります。SqlDataAdapter.Fill()タイムアウト - 基盤となるSprocはすぐに返されます

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. 

ありがとうございます! -Chris

答えて

0

.NETはプロシージャから戻ってくるデータを解析しているため、Fill()は時々遅くなることがあります。

SQLプロファイラを使用して、Fill()が実行されたときにSQL .NETが実際に送信する内容を確認します。

それは、あなたのストアドプロシージャスピード物事を、これらの同じセット文をアップして置く。..など

 
set concat_null_yields_null on 
set cursor_close_on_commit off 
set implicit_transactions off 

etc... 

として、SET文の多くを送信している場合。

2

ありがとうございました。 SPROCを使用していた参加に、この解決策は、(NOLOCK)ステートメントで追加することであった:内部結合cはcategory_tbl FROM

dbo.categoryItem_LNK Clで(NOLOCK)ON c.categoryid = cl.categoryid

SqlDataAdapterを使用しているときに劣化が見られたのはなぜかわかりませんが、これがすぐに問題を解決しました。

おかげで再び、 クリス

+0

これは私にとってもうまくいきました。テーブル値関数から10個のレコードを抜いてもタイムアウトしました。 – Sergey

+0

私は同じ問題をクエリを実行していましたが、 "WITH(NOLOCK)"を使用すると助けになりませんでした。クエリの最後に "OPTION(RECOMPILE)"を追加すると問題が解決しました。 – sharpguru

1

は私がニュースを壊すことを憎むが、(NOLOCKを)ソリューションではありません、それだけで汚れが/重複データの欠落、読み、さらには中止されたクエリなど、new problemsを作成します。 SQLデータベースのロックはあなたの友人です。

ロックしている(または悪化している)と速度が遅い場合は、SSMSで実行されている接続オプションとアプリケーションで使用されている接続オプションを比較します。 SQLプロファイラを使用して、コードの実行方法を確認します。

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

+0

実際は、ユースケースによって異なります。おそらく、あなた自身のユースケースに懸念を抱かせるほどの深刻な問題であるかどうかを読者が判断するのを助けるために、「新しい問題を生み出す」ということで拡大する可能性があります。 – Dan

0

不適切なクエリプランとパラメータスニッフィング。格納されたproc、特にパラメータが乱読された行を調整する場所では、入ってくるパラメータを調べることによる悪い実行計画が原因です。異なる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

3

私は、これは7のように、遅すぎる知っていますあまりにも遅い!私は今日この問題に反対し、私の修正を分かち合いたいと思った。私の例では、SQLから引き出されたデータはテーブル値関数でした。テーブル値関数は約3500行しか返しませんでしたが、1秒未満でしたが、C#コードのFill()でタイムアウトしました。私は誰がどのように動作するのかわからないが、機能を落として再作成することでそれを修正した。私は、.NETがSQLによって与えられたデータをどのように読み込むのかと何かと思っています。たとえば、レポートで使用された後に変更を加えれば、ビューを再作成する必要があります。私は100%確信していませんが、私のためには素早い修正でした。

+0

これは私にとってそれを解決しました。私のspの開始時に 'floor'と 'ceilings'の日付パラメータを持つ関数呼び出しがあった。私はその機能を削除し、手動で '床'と '天井'を行い、それが機能しました。 –

+0

私たちのケースでは、ストアドプロシージャを単に削除して再作成するだけで、この問題は解決しました。安全対策のために、我々はどこにでも(NOLOCK)が含まれていることを確認しました。 SQL Serverのバグを今すぐに - MongoDBを使うのがベスト – sean2078

1
da = new SqlDataAdapter(cmd); 
da.SelectCommand.CommandTimeout = 1800; 
+1

この最初の[how-to-answer]を見てください(https://stackoverflow.com/help/how-to-answer) –

関連する問題