SSIS にはこのようなシナリオ向けのインテリジェンスが多数組み込まれており、時間を投資するのにおそらく最善の策であるという John の意見に同意します。
レコードのような問題には、データを分割することによってアプローチします。物理的なストレージのパーティショニング (つまり、テーブルのパーティショニングの追加) について話しているのではなく、論理的な処理のパーティショニングについて話しているのです。2ミルを分割します。データアクセスレベルで利用できる条件に基づいて、N パーティションのレコード。インデックス付きの列を作成し、それぞれ独自のパーティションでチャーンを開始する N 個のプロセッサを割り当てます。アイデアは、同じ行にアクセスしようとする際にプロセッサが重複しないようにすることです。「プロセッサ」はスレッドである場合もあれば、非同期データベース アクセス メソッドを使用するワーカー アイテムをキューに入れている ThreadPool である場合もあります。
大きな問題は、多くの場合、適切なパーティショニング キーがないことです。このような場合、次のようなアドホック パーティショニングを実行できます。
with cte as (
select top (@batchSize) *
from myTable with (rowlock, updlock, readpast)
where <record is ready to be processed>)
update cte
set <mark record processing>
output inserted.*
秘訣は、select で使用されるロックのヒントです。force と updlock により、現在のプロセッサによる処理のためにレコードがロックされます。readpast ヒントを追加することにより、各プロセッサは、他のプロセッサによって既にロックされているレコードをスキップします。このようにして、各プロセッサは、処理が何であれ、処理するレコードの独自の @batchSize バッチを取得します。
これらのコメントはすべて、Web サービスの呼び出し、紙伝票の印刷など、データベースの外部に関係する処理に適用されることを理解することが重要です。処理がすべてデータベース内にある場合は、それを単一の T-SQL 更新として表現し、クエリ オプティマイザーが適切と思われる並列クエリを使用できるようにする必要があります。