13

私が読んだものから:

テーブルまたはビューのデータアクセスモードは、トランザクションとして一度に各行をコミットします。したがって、500万行を転送するパッケージの作成には時間がかかります(30分以上)。

高速ロードデータアクセスモードでは、宛先に挿入するときにバッチ行とコミットサイズを指定できます。たとえば、500万件のレコードを挿入するには、2分強かかります。

ここで、DWにロードするSSISパッケージの1つが、OLEDB宛先でテーブルまたはビューデータアクセスモードを使用する場合に問題が発生します。私の理解では、これは、エラーレコードテーブルに挿入するエラー行(エラー制約)を取得するためです。したがって、30分以上かかるプロセスがあります。同様に、Fast-Loadは同じアクションで2分未満かかります。

私が正しく理解していれば、fast-loadは、バッチでエラーを引き起こした行を区別できず、バッチが完全に失敗しますか?もしそうなら、エラー行のあるバッチがエラー制約によってリダイレクトされ、バッチ内の適切なレコードが正しい宛先に送信され、それでもエラーログテーブルにエラーレコード?そうするのも良い考えですか?それがかかる時間に関して、弾丸のような話をする方が良いですか?

前もって感謝します。

4

2 に答える 2

15

その状況で私が見たのは、カスケード障害アプローチです。シングルトン挿入を開始する前に、バッチ モードを使用してできるだけ多くのデータを取得するために、小さなバッチを連続して OLE DB 変換先に挿入してみてください。

コミット サイズが 10,000 行であると仮定します (任意の数、状況のテストなど)。失敗した行を OLE DB 宛先にリダイレクトします。高速読み込みモードのままですが、コミット サイズは 2.5k 行です。おそらく 100 のコミット サイズで、さらに別の ole db 宛先を追加し、最終的な宛先を RBAR モードにします。その後、失敗した行を特定し、必要な処理を実行できます。

于 2013-01-22T19:41:35.203 に答える