これまでに作成したすべての ETL について、トランザクションを作成したことはありません。つまり、表 4 が失敗した場合は、すべてをロールバックします。
この点でのベストプラクティスは何ですか?
「BeginTran + Commit」するか「BeginTran + Commit」しないか
編集: 4 つの他のパッケージを呼び出す 1 つのマスター パッケージがあります。それらすべてを 1 つのトランザクションにまとめることができますか?
これまでに作成したすべての ETL について、トランザクションを作成したことはありません。つまり、表 4 が失敗した場合は、すべてをロールバックします。
この点でのベストプラクティスは何ですか?
「BeginTran + Commit」するか「BeginTran + Commit」しないか
編集: 4 つの他のパッケージを呼び出す 1 つのマスター パッケージがあります。それらすべてを 1 つのトランザクションにまとめることができますか?
管理可能なバッチサイズで begin+commit します。毎晩 6 時間のインポートを 1 つのトランザクションにラップする必要はありません。バッチは、せいぜい 2 ~ 3 分で終了できるサイズに維持してください。ETL に失敗するデータ純度の問題が発生することは当然のことなので、少なくとも影響を管理可能なものに減らします (つまり、完了までにさらに6 時間かかるロールバックをトリガーしないでください)。
SSIS では、私は常にBegin Trans + Commit
. パッケージが失敗した場合、問題なく (または実際に挿入された行を見つける必要なく) パッケージを再実行できるようにしたいと考えています。
リカバリとクリーンアップが非常に簡単になります。
多くの場合、ETL で移動するデータが多すぎて、SQL トランザクションを使用できません (ロールバックするには、ログにすべてのデータを保存する必要があります)。非破壊的に再実行できるようにパッケージを設計することを好みます。理想的には、ストリームの途中で死亡した場合に開始するだけで、ほぼ中断したところから続行できるように設定する必要があります。そのためにパフォーマンスが低下することもありますが、それだけの価値があると思います。
技術的には、パッケージを 1 つのトランザクションにまとめることができます。実際にはそうではないかもしれません。