質問: 私はバルク負荷のパフォーマンスを向上させるために取り組んでいます。毎日何百万件ものレコードが100件あります。 データテーブルの代わりに`IDatareader`インターフェイスを使用するようにこれを変更し、パフォーマンスが大幅に向上しました(毎分50万レコード増加)。現在の設定は次のとおりです。 * 区切られたファイルを解析するためのカスタムキャッシュリーダ。 * ストリームリーダーをバッファリングされたストリームにラップします。 * オブジェクトを列挙し、 `IDatareader`インターフェイスを実装するカスタムオブジェクトリーダークラス。 * その後、 `SqlBulkCopy`はサーバーに書き込みます パフォーマンスボトルネックの大部分は`SqlBulkCopy.WriteToServer`直接あり`SqlBulkCopy.WriteToServer` 。私が`WriteToServer`だけを除いてテストすれば、プロセスは約1分で復帰します。 `WriteToServer`はさらに15分以上かかる。単体テストの場合、ローカルマシン上にあるので、データベースが同じドライブ上にあるため、ネットワークを介してデータをコピーする必要はありません。 私はヒープテーブルを使用しています(インデックスはありません;クラスター化されているか、クラスター化されていません。 負荷時間を減らす必要があるので、誰かがこのターンアップからもう少し血を絞ることができると期待しています。
回答: なぜSSISを直接使用しないのですか? とにかく、あなたがIDataReaderにパースするのをやめたのであれば、あなたはすでに正しい道にいます。 SqlBulkCopy自体を最適化するには、フォーカスをSQL Serverに変更する必要があります。キーは最小限の操作で記録されます。以下のMSDN記事を読む必要があります。 * 一括インポートにおける最小限のログの前提条件 * 一括インポートパフォーマンスの最適化 。 あなたのターゲットがBツリー(つまり、クラスタ化されたインデックス付きテーブル)の場合、不幸なことに、パフォーマンスの一括挿入の最も重要な教訓の1つ、つまりソートされた入力行セットは宣言できません。これはシンプルなので、ADO.Net SqlClientには`SSPROP_FASTLOADOPTIONS -> ORDER(Column)` (OleDb)と同等の機能はありません。エンジンはデータが既にソートされていることを知らないので、ソート演算子をプランに追加します。こぼれないように、小さなバッチサイズ(〜10k)を使用してください。私のオリジナルポイントを参照してください:これらはすべて、OleDB MSDN仕様を掘り下げるのではなく、SSISで設定するオプションとクリックです。 あなたのデータストリームがソートされていない場合、またはデスティネーションがヒープの場合、上記の私のポイントはミュートです。 しかし、最小限のロギングを達成することは、まともなパフォーマンスのために必須です。