2

セットアップしたすべてのフラット ファイル コネクタで次のエラーが発生します。フラット ファイル コネクタは、データ フロー タスクで ADO.NET から設定されます。

データ フロー タスク [フラット ファイル送信先 11 [1230]] でのエラー: フラット ファイル送信先 11.Inputs[フラット ファイル送信先入力] の入力列の数をゼロにすることはできません。

データ フロー タスク [SSIS.Pipeline] でのエラー: "Flat File Destination 11" が検証に失敗し、検証ステータス "VS_ISBROKEN" が返されました。

データ フロー タスク [SSIS.Pipeline] でのエラー: 1 つ以上のコンポーネントが検証に失敗しました。

データ フロー タスクでのエラー: タスクの検証中にエラーが発生しました。

次のように、入力に列があることを確認しました。

フラットファイルは列を正しく読み取っているようです

私のデータフローは次のようになります

ここに画像の説明を入力

メタデータは適切に見えます

ここに画像の説明を入力

列のマッピング

ここに画像の説明を入力

4

1 に答える 1

9

このようなデータ フローを構築しないでください。検証にはしばらく時間がかかり (コンポーネントは次々と検証されます)、それらはすべて同じデータ フロー内にあるため、限られた数のコンポーネントが並行して実行されます。また、これらのソースがすべて同じ DB にヒットしている場合、ロックの問題が発生する可能性があります。 「データ フロー内のソースが多すぎる」を参照してください。

すべてのフラット ファイルの宛先に入力列がマップされていることを確認しても、このエラーが引き続き発生する場合は、SSIS データ フローが適切に処理/検証するには、ソース/宛先マッピングが多すぎる可能性があります。 . 以下のデザインの代替案のいずれかを試してみてください。

管理性とパフォーマンス

このように多くの目的地を扱っている場合は、管理しやすいアプローチをお勧めします。Source -> Destination マッピングのそれぞれでメタデータが同じである場合、単一のデータ フローでこの ETL を実行できます。

  1. 「SourceQuery」列と「OutputFileName」列を含む DB テーブルを作成する
  2. ソース/出力マッピングごとにテーブルに行を追加します
  3. 制御フローで、テーブルからすべての行を選択します
  4. ResultSet を完全な結果セットに設定します
  5. 結果をオブジェクト変数 (objResultSet) に格納します。
  6. Foreach ループ コンテナーを ADO 列挙子と共に使用して、objResultSet から各行を読み取ります。
  7. 結果セットの列をパッケージ変数にマップする
  8. 式を使用して SourceQuery 変数を ADO.NET ソース クエリにマップする
  9. OutputFileName 変数をフラット ファイル接続マネージャーのファイル パスにマップする

管理容易性よりもパフォーマンスの方が重要であると感じ、シナリオにさらに並列処理を追加したい場合は、いくつかの異なる点を考慮することができます。どのアプローチを取るかは、これらのソース クエリがどの程度異なるか、および計算を DB レベルで行うか、SSIS データ フロー内で行うかによって異なります。これを行うにはいくつかの方法があります。ここでは、留意すべき点をいくつか示します。

  • 複数のデータ フロー タスクを使用すると、より多くの並列処理が可能になり、通常、1 つのデータ フローに複数のソースがある場合よりもパフォーマンスが向上します。データ フローで複数のソースを使用する必要があるのは、行をマージ/結合する場合のみです (結合はソース クエリでは実行できません)。
  • 必要なすべてのデータが 1 つのソース クエリに収まる場合は、1 つのソース コンポーネントと Conditional Split 変換を使用して行を適切な宛先に送信します。
  • 複数のパスで同じ行が必要な場合は、マルチキャスト変換を使用します
  • Aggregate Transform を使用して合計/カウントを計算できますが、代わりにこれをソース クエリにプッシュする方が高速な場合があります。
于 2013-05-16T14:45:12.673 に答える