行40,000で失敗したことを「認識」し、再起動すると行40,001のストリーミングを開始する必要があることを私が知っているネイティブマジックはありません。チェックポイントが答えではなく、独自の問題がたくさんあることは正しいです(オブジェクトタイプをシリアル化できない、ループが再起動するなど)。
この問題に対処する方法は、優れた設計によるものです。パッケージが失敗することを期待して作成されている場合は、これらのシナリオを処理できるはずです。
私が精通している2つのアプローチがあります。最初のアプローチは、ソースと宛先の間のデータフローにルックアップトランスフォーメーションを追加することです。これの目的は、ターゲットシステムに存在するレコードを特定することです。一致するものが見つからない場合は、それらの行のみが宛先に送信されます。これは非常に一般的なパターンであり、送信元と宛先の間の変更を検出することもできます(必要な場合)。欠点は、常にソースシステムから完全なデータセットを転送してから、データフローの行をフィルタリングすることです。1,000,000行のうち99,999行で失敗した場合でも、送信されていない1を見つけるために、1,000,000行すべてをSSISにストリーミングして戻す必要があります。
もう1つのアプローチは、ソースのWHERE句で動的フィルターを使用することです。行が順番に挿入されるような仮定を立てることができる場合は、Destinationデータベースに対してExecute SQL Task
クエリを実行する場所のようにSSISパッケージを構造化SELECT COALESCE(MAX(SomeId), 0) +1 AS startingPoint FROM dbo.MyTable
し、それをSSIS変数(@ [User :: StartingId])に割り当てることができます。 。次に、ソースからのselectステートメントで式を使用して、次のよう"SELECT * FROM dbo.MyTable T WHERE T.SomeId > " + (DT_WSTR, 10) @[User::StartingId]
にします。データフローが開始されると、最後にデータがロードされた場所から開始されます。このアプローチの課題は、データが順不同で挿入されていないことがわかっているシナリオを見つけることです。
ご不明な点がある場合、より適切に説明する必要がある場合、写真などをお知らせください。また、上記のコードはフリーハンドであるため、構文エラーが発生する可能性がありますが、ロジックは正しいはずです。