0

SQL Server 2000 データベースに対する非常に長いクエリがあり、C# アプリケーションでさらに処理するために結果を返しています。

次のクエリを検討してください。

declare @sn varchar(20)

select distinct serial_number 
from manufacturingData 
where '7/19/2012'<date_time
order by serial_number

while (0 < (select count(serial_number) from #sn)) begin
  select top 1 @sn=serial_number from #sn
  exec sp_GetSnData @sn
  delete from #sn where serial_number=@sn
end
drop table #sn

このクエリを に書いている07/19/2012ので、今日のレコードのみが返されます。

上記のクエリ (今日の半分) は、119 個の異なるシリアル番号を返し、それに付随する while ループの実行に 52 秒かかりました。

通常、このレポートは 30 日間実行され、約 3500 の部品番号があります。

生成された結果にアクセスできるように、結果セットに「フック」する方法はありますか?

現在のやり方では、クエリに 2 分かかるのか、2 日かかるのか、それともまだ何かを実行しているのかは誰にもわかりません! マネージャーはコンピュータをシャットダウンしてその日のうちに家に帰りますか、それともこのレポート クエリはもうすぐ終了しますか?

個々のテーブルが返されたら、各テーブルを個別に処理する必要があります。

できればよかった

  • 返された個別のアイテムの数を確認し、
  • 現在問い合わせ中の項目
  • 次のテーブルが来るのを待っている間に、結果のテーブルを処理できるようにします。

これは可能ですか？

参考までに: 私は現在、サーバーに個々の要求を送信することにより、Windows フォームでこれを行っていますが、これはサーバーを停止させ、利用可能なすべての接続を使い果たしています。

4

2 に答える 2

2

これは、ストアドプロシージャを使用せず、代わりにセットベースのコードを記述したい場合です。1つのレコードの処理から多数のレコードの処理に移行する場合、コードの再利用はしばしば悪いことです。

または、カンマ区切りのリストを送信して一時テーブルに解析し、作業を実行できるように、プロシージャを修正します。procが何をするのかわからないので、これを行うための実際のコードを提案します。次に、ボットの単一入力および複数の入力パラメーターを処理できます。

ところで、最初にシステムprocで、次にユーザーprocで検索されるため、sp_プレフィックスを使用してprocに名前を付けないでください。これにより、実行ごとにパフォーマンスが低下します（個々に小さいですが、システム全体で合計される可能性があります）。すべてのprocの、そしてシステムprocが同じ名前で終わる場合、それはあなたのものではなくそれを使用します。

于 2012-07-19T20:58:55.940 に答える
1

あなたのコメントに基づいて、ストアドプロシージャを最適化しようとしています。

ただし、所要時間をすばやく簡単に示したいだけの場合は、

ただする

select Count(distinct serial_number)  from manufacturingData  where '7/19/2012'< date_time

そして、大まかなパフォーマンスの数値に基づいて、たとえば.5秒というフィドル係数を掛けます。

進行状況が必要な場合は、SQL Server DMO を参照してください。基本的には、ループ内に Print ステートメントを配置します。SMO は出力を取得してイベントをトリガーします。進行状況バーなどを駆動するハンドラーを追加します。

注: DMO は 2000 で動作し、後方互換性パックを入手できるので、2005 および 2008 で動作します。(現時点では 2012 でも動作します) が、サポートされていないため、引き続きこれに依存するのは気が進まないでしょう。そうするために。2005 年から DMO は SMO に置き換えられました。

私は、迅速な勝利のために、最初にspの最適化に取り組んでいます。

于 2012-07-25T16:31:30.287 に答える