1

.NET アプリケーションから SQL Server データベースに対して実行しているクエリがあり、完了するまでにかなりの時間がかかるようです (5 分以上)。私は c# でテスト アプリを作成して、何が長い間話されていたかを確認しようとしました (クエリはすぐに返されるはずです)。

要素を追加してどの部分が非常に時間がかかっているかを確認してクエリを再構築していたので、元のクエリのスペースと大文字と小文字の違いだけが唯一の違いである、実質的に逐語的にクエリを再構築することになりました。この違いは、約 100 ミリ秒で結果を返しました。

誰もこれを見たことがありますか？私たちのサーバー (同僚が同じ問題を抱えているため) またはコンピューターでオフになっているサービスがあるかどうか疑問に思っています。

これについてご協力いただきありがとうございます。

以下のコード例 (最後のクエリの最初の行の違い (fk_source と fk _Source):

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);
4

7 に答える 7

3

これはプロシージャ キャッシュの問題であると思われます。ストアド プロシージャの利点の 1 つは、プランが保存されるため、作業が高速化されることです。残念ながら、(動的クエリを使用している場合でも) キャッシュに不適切なプランが含まれる可能性があります。

冗談で、プロシージャ キャッシュをチェックし、アドホック クエリを実行し、再度チェックした後、同じクエリを別の大文字で実行したところ、プロシージャ カウントが高くなったことに驚きました。

これを試して....

SQL Server Management Studio に接続します。

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

ステートメントが変更されると (唯一の変更が大文字と小文字を区別する場合でも)、TotalProcs が変更されることがわかると思います。

統計を更新すると役立つ場合があります。これはかなり遅い実行プロセスであるため、遅い時間帯に実行することをお勧めします。

于 2008-09-29T20:04:19.187 に答える
1

SQL Server 2005 を使用しているので、OleDbCommand オブジェクトの代わりに SqlCommand オブジェクトを試しましたか?

于 2008-09-29T18:36:09.257 に答える
1

パフォーマンスに影響を与えるクエリの違いは見られません。実行間のキャッシュまたはインデックス/統計の変更はどうですか? 統計またはインデックスの変更により、実行計画が変更された可能性があります。

大文字と小文字について: データベースが大文字と小文字を区別するように設定されている場合、大文字と小文字が区別される可能性がありますが、両方のクエリを大文字と小文字を区別するデータベースで実行するには、両方の形式で名前が付けられた列が必要です-クエリパーサーは大文字と小文字に従います-パフォーマンスの違いは発生しません。

于 2008-09-29T18:38:32.123 に答える
0

最も完全な回答をくれた G Mastros に感謝しますが、振り返ってみると、統計の更新は Cade によって提案されました。しかし、G Mastos のソリューションは、私の SQL Server の経験レベルにより適していました。

みんな助けてくれてありがとう！

この一見無害に見える違いが、なぜこれほどまでに大きな結果をもたらすのかを調べていきます。

于 2008-09-29T22:12:55.040 に答える
0

まず、クエリが間違っていると 100% 確信していますか? SQL Server のトレース プロファイルをチェックして、DB での所要時間を確認します。

次に、同じ数の結果が返されますか。SQL Server ではデフォルトで大文字は問題にならないはずですが、別の方法で設定されている可能性があります。

于 2008-09-29T18:39:26.893 に答える
0

「5分以上」かかるクエリがあった場合、文字列の大文字と小文字を一致させるのにかかる100ミリ秒について心配することはありません.

于 2008-09-29T18:40:51.960 に答える
0

すべての回答に感謝します。それぞれに順番に返信します。

1) Russ、SQLConnection の方が優れていることに同意しますが、残念ながら接続の種類を設定できません。このクエリをテストするために小さなアプリを作成しましたが、クエリははるかに大きなアプリケーションで動的に作成されます。

2）gbjbaanb、サーバーの問題ではないと思います。管理スタジオから両方のクエリをほぼ同時に実行できるため、.net（1.1および2.0）でoledbを実行する場合にのみ問題になるようです。プロファイラーを実行したところ、この方法で呼び出した場合、クエリを完了するのに 5 分以上かかったことがトレース ファイルで確認されました。

3) Joel Coehoorn、同意しましたが、ここで私が言おうとしているのは「理由」です。現在、この問題がどれほど大きく、どこにあるのかわからないからです。

4)Cade Roux、違いは非常に再現可能です。したがって、同じ結果でテストを連続して実行し、SQL Server でほぼ同じ時間がかかるため、インデックスの変更やキャッシュの問題ではないと思います。走る。

于 2008-09-29T19:04:10.297 に答える