4

現在、大規模なデータ移行の演習に SSIS 2012 を使用しています。

完了するタスクがありますが、最善のアプローチがわかりません。

テーブル A には 210 万のレコードがあります。

各行を繰り返す必要があります。

ステップ 1. テキスト操作を行う複雑なサブクエリの結果で特定のフィールドを更新する

ステップ 2. TableA 行
2a の電子メール フィールドから電子メール アドレスを取得します。ユーザーテーブル
2b を検索します。電子メールが存在する場合は、ID を取得し、TableA 行
2c の UserId を更新します。メールが存在しない場合 - 新しいレコードを User テーブルに挿入し、ID を取得して TableA 行の UserId を更新します

ステップ 1 と 2 は同時に実行する必要はありません。これらのタスクは無関係であるため、別々のデータ フローに分割できます。

これはすべてカーソルを使用して記述できます。非常に簡単ですが、一般的なルールとして、カーソルを使用することは嫌われています。

新しい MERGE 関数を使用して、上記のステップ 1 の純粋な SQL スクリプトを作成しました。それが使用するサブクエリはビューを呼び出し、ビューはスケーラー関数を使用して複雑なテキスト操作を行います。これが SSIS 経由で 1 時間 12 分実行された後、tembDB.log がディスク領域を使い果たしたため、SSIS が爆発しました。

私のクエリが tembDB が制御不能になった原因なのか、それとも以前に実行された SSIS パッケージの何かが原因なのかわかりませんか? どうすればわかりますか？

上記のステップ 1 と 2 の両方を達成するための SSIS 内の最適なツールに関するヒントはありますか?

4

2 に答える 2

1

生の SQL ではなく SSIS を使用することを制限するものは何なのか疑問に思っています。これは通常のデータ フィードではなく、1 回限りの作業ですか? 1 回限りの場合は、ソース データを宛先 DB (または同じサーバー上の別のステージング DB) のステージング テーブルにプルし、そこで複雑なことを行いたくなるでしょう。SSIS は、繰り返される定期的なデータ フィードに最適です。これが必要ない場合は、SQL を使用します。

(TBH、SSIS のより高度な機能である行レベルの操作の一部についてはまだ調べていません)。

ステップ 2 を 2 つの SQL ステートメントに分割し、別々のセットで操作することができます。

を。電子メールが存在する行のセット。

b. 電子メールが存在しない行のセット

個々の行ではなく、開始する前に行の「トリアージ」を作成します。2 つのセットがテーブル全体をカバーしていることを慎重に確認します。SSIS を使用する場合は、SSIS の個別のデータ フローでこれを行うことができます (テーブル全体をダンプするだけでなく、ソース DB でそれに対して SQL を実行できる限り)。

于 2012-11-29T16:14:18.953 に答える
0

ステップ 1 の場合、「複雑なサブクエリ」に相当する SSIS は、通常、ルックアップを伴うデータ フローです。「テキスト操作」/「スカラー関数」に相当する SSIS は、通常、スクリプト変換を伴うデータ フローです。T-SQL でコード化できる操作はすべて .NET で実行できます。正規表現、HTMLEncode などの .NET ライブラリを利用でき、より洗練され、より高速に実行される可能性があります。

ステップ 2 では、TableA から個別の電子メール値を提供する OLE DB ソースを使用して、新しいデータ フローを開始します。次に、ルックアップ変換を追加して、「ユーザー テーブル」と照合します。一致を無視し、一致しない行を OLE DB Destination に送信して、「ユーザー テーブル」に挿入します。

次に、TableA のすべての行を取得し、「ユーザー テーブル」の値を検索して、ロットをステージング テーブルに挿入する別のデータ フローを追加します。すべてを TableA に戻す必要がある場合は、この時点で切り捨てて再ロードできます。更新やカーソルよりもはるかに高速です。

于 2012-12-01T23:42:32.160 に答える