同じパッケージを並行して実行できる非常に複雑なシナリオがあります。状況によっては、両方の実行が同じ行を挿入先に挿入しようとすることになり、主キー違反エラーが発生することがあります。
現在、宛先テーブルをチェックしてレコードが存在することを確認するルックアップがあるため、「一致しない」出力で挿入が行われます。ルックアップはパッケージの開始時に読み込まれるため、エラーを防ぐことはできません。したがって、両方のパッケージが同じデータを取得し、行が入った場合、両方とも「新しい」行と見なされるため、最初の行は成功し、2 番目の行は失敗します。 .
このシナリオを回避するためにできることはありますか? oledb 宛先の「重複行」をほとんど無視しますか? 重複する行は、最初のパッケージにはなく、挿入する必要がある他の行の中にあるため、MAX ERROR COUNT を使用できません。
デフォルトのルックアップ動作では、フル キャッシュ モードが使用されます。ご覧のとおり、パッケージの検証段階で、すべてのルックアップ値がローカル メモリ キャッシュに取り込まれ、それが使用されるため、テーブルの更新が失われます。
あなたのシナリオでは、キャッシュモードをに変更してみますNone(部分は他のオプションです)。None は、通過する行ごとにターゲット データベースに対して実際のクエリを実行する必要があることを示します。データ量やパフォーマンスの低いクエリによっては、送信先に少なからず影響を与える可能性があります。並列インスタンスがまったく同じレコードをロードしようとしていないこと (または並列実行が既にルックアップを満たし、ターゲット テーブルに書き込む準備ができていること) を保証するわけではありませんが、状況は改善されるはずです。
同時データフローが起動するようにパッケージの実行を制御できない場合は、アプローチの再設計を検討する必要があります (パーティションに書き込み、スワップインし、何かを使用してリソースをロックし、すべてのデータをステージングし、TSQL マージを使用するなど)。
ちょっと考えてみてください...新しいレコードを一時テーブルに書き込んで、断続的にマージするのはどうですか? これにより、重複を除外する機会が得られます。