SQL Serverテーブルの高速ロードが

です。ステージングテーブルに500K行（約30列）をロードするSSISパッケージを継承しました。SQL Serverテーブルの高速ロードが

これは約120分ほど調理されていますが、まだ完了していません。これは、1秒あたり70行未満で実行されていることを示しています。私は誰もが環境は違っていると知っていますが、これは「典型的」から数桁も離れていると思います。

奇妙なことに、ステージングテーブルにはINT（ID）列のPK制約がありますが、負荷のパフォーマンスを妨げる可能性があると私は考えています。ステージングテーブルには他の制約、インデックス、トリガはありません。

提案がありますか？

----追加情報------
ソースは、いくつかの静的データ（実行日とバッチID）をストリームに追加する2つの別々のデータフローコンポーネントに接続するタブ区切りファイルです、次いで

アクセスモードがOpenRowsetをがFastLoadの

を使用しているOLE DB先アダプタに接続する

FastLoadOptionsはTABLOCK、CHECK_CONSTRAINTS

ある

最大挿入コミットサイズ：0

出典

2009-05-13 Ralph Shillington

あなたは、データの外観とテーブル構造の例を挙げることができますか？ – DForck42

PKの制約があっても、それよりもはるかに優れているはずです。あなたはSSMSのロックを見ることができますか？ nolock/uncommittedを使用してステージングテーブルにクエリを実行して、何も追加されていないかどうか確認しましたか？ – Tomalak

私自身の質問に答える礼儀についてはわかりません。これがコメントに適しているのであれば、事前に申し訳ありません。

問題は、テキストファイルの入力列のデータ型です。これらはすべて「テキストストリーム[DT_TEXT]」として宣言されていましたが、これを「String [DT_STR]」に変更したとき、 "典型的"の領域にあります。 - そのように宣言されたときに、テキストファイルのソースが何をしているのか分かりませんが、今は私の後ろにあります！

出典

2009-05-14 03:21:08

理由を共有してくれてありがとう。 – Tomalak

あなた自身の答えが解決策をより良く説明していると思われる場合は、自分の質問に答えるのがいいです。また、それが解決されたことを人々が知っているように受け入れられた回答としてマークしてください。 – Coops

1つの大きなトランザクションで実行されている場合、そのことが説明される可能性があります。今すぐコミットが行われることを確認してください。

また、リソースの問題を排除するために、プロセッサの負荷、メモリ、IOをチェックすることもできます。

出典

2009-05-13 21:35:03 stili

私は何らかの問題があると言いたいのですが、2000万レコード以上のカラムとアイデンティティフィールドを持つファイルからステージングテーブルを一括して挿入し、それよりはるかに短い時間でSSISがより高速になるはずですSQL Server 2000の一括挿入。

ブロックの問題を確認しましたか？

出典

2009-05-13 21:35:16 HLGEM

これは言うのは難しいです。

私は複雑なETLがありました。データフローで許容されるスレッドの最大数を確認し、いくつかのことが並行して実行できるかどうかを確認します。

しかし、それは単純な転送のように聞こえる。

50万行の場合、バッチ処理はオプションですが、その数行は必要ないと思います。

PKの識別情報は問題ではありません。宛先に複雑な制約や計算された列が残っていますか？

これは低速ネットワークリンクをプルまたはプッシュオーバーしていますか？複雑なSPやビューから引き出したり押したりしていますか？データソースとは何ですか？

出典

2009-05-13 21:50:35

SQL Serverテーブルの高速ロードが

答えて

関連する問題