基本的に 26 個のテーブルを oracle から sql サーバーにコピーしようとするパッケージがあります。完全なテーブル コピーではありません。当社の特定の「地域」に属するレコードを探しています。
私はオラクルからデータを引き出します。私は肘のグリースでこれを始めたばかりですが、26のテーブルのそれぞれには、削除、フェッチなどを行うためにいくつかの変数が必要でした.
簡単に言うと、変数を使用してテーブル名 (ソース、一時、およびターゲット) を表すことにしました。
これにより、1 つのシーケンスをコピーして貼り付けることができ、入札の多くのクリック クリックを効果的に回避できました。
私が直面している問題は、メタデータが非常に壊れやすいように見えることです。シーケンスはすべて独自に実行されているように見えますが、パッケージ全体を実行すると壊れます。そして、決して同じ場所ではありません。
このアプローチは、SSIS では悪い考えですか?
これをボードから外すだけです....
各シーケンス コンテナには次の ops がありました
スクリプト タスク - 変数を設定する SQL タスクを実行する - 一時データ フローから削除するSourceToTemp - ole
db ソース - 一般的な選択を使用するこれは大きな問題の子です) SQL タスクの実行 - ターゲットからの削除 SQL タスクの実行 - ターゲットの挿入 temp からの選択
oleDB の宛先は壊れ続けた部分です。
これは変数を参照するため、データ フローの 1 つを開く前に、設計時に変数を正しく設定するように細心の注意を払う必要がありました。
これが問題だと確信しています。設計環境で SSIS がいつメタデータを更新するかを確実に言うことはできないため、変数がシーケンス Y をサポートするように設定されている間に、シーケンス X が更新されたかどうか、いつ更新されたかはわかりません。
したがって、概念的には実行時に機能するはずですが、開発時間は変更管理の悪夢です。
ハードテーブル名を指すように、すべての oleDB 宛先を変更しました。まだ変数によって駆動される 4 つの sql ステートメントがあるため、これは実際には小さな譲歩です。（クリックと入力の多くを節約できます）
この小さな変更により、「移動する砂」の問題が解消されました。
教訓 : oledb の宛先を変数に基づいてはいけません。
コメントありがとう