ソースから毎日 600,000 行を取得しており、それらを SQL Server の宛先にダンプする必要があります。これは増分ロードになります。
現在、宛先テーブルのサイズは日々増加する可能性が高いため、これが増分ロードの最良のアプローチです。私はいくつかの選択肢を考えています:
ルックアップ タスク
マージ ジョイン
SCD
等..
増分負荷でうまく機能する最適なオプションを提案してください。
ソースから毎日 600,000 行を取得しており、それらを SQL Server の宛先にダンプする必要があります。これは増分ロードになります。
現在、宛先テーブルのサイズは日々増加する可能性が高いため、これが増分ロードの最良のアプローチです。私はいくつかの選択肢を考えています:
ルックアップ タスク
マージ ジョイン
SCD
等..
増分負荷でうまく機能する最適なオプションを提案してください。
Andy Leonard の優れたStairway to Integration Servicesシリーズまたは Todd McDermid のビデオ (無料のSSIS Dimension Merge SCD コンポーネントの使用方法) を参照 してください。どちらも、このボックスで列挙できるよりもはるかに適切にそれを行う方法を説明しています。
マージ結合は、すべてのレコードを前もって並べ替える必要があるため、パフォーマンスに大きな問題があり、これには使用しないでください。
毎日数百万のレコード ファイルを処理し、通常はそれらをステージング テーブルに配置し、変更データ追跡テーブルのデータとハッシュ比較を行って、データが本番環境のものと異なるかどうかを確認し、新しいファイルまたは新しいファイルのみをロードします。違います。実稼働データベースの外部で比較を行うため、数百万のレコードを実稼働に対してチェックする代わりに、実際に必要な 247 のみを処理するため、実稼働にはほとんど影響しません。実際、私たちの最も忙しいサーバーでは、この処理はすべて別のサーバーで行われますが、本番環境への最後のステップは例外です。
それらを挿入するだけでよい場合は、実際には問題ありません。if exists, update else insert のようなものを確認する必要がある場合は、600.000 行をクエリし、既存のデータソースのルックアップ タスクでそれらが存在するかどうかを確認する oleDbSource を作成することをお勧めします。既存のデータソースは巨大 (または巨大になりがち) であるため、キャッシュ モードの設定方法には注意してください。私はあなたが探しているIDによって順序付けられたいくつかのメモリ制限で部分キャッシュを使用します(この詳細はキャッシュの仕組みに基づいて非常に重要です)