SqlBulkCopyのパフォーマンス

Question

バルクロードのパフォーマンスを向上させるために取り組んでいます。毎日何百万件ものレコードが100件あります。

これをデータテーブルの代わりにIDatareaderインターフェイスを使用するように変更し、パフォーマンスが大幅に向上しました（1分あたり50万レコード増加）。現在の設定は次のとおりです。

• 区切られたファイルを解析するカスタムキャッシュリーダーです。
• ストリームリーダーをバッファリングされたストリームにラップします。
• オブジェクトを列挙し、IDatareaderインターフェイスを実装するカスタムオブジェクトリーダークラスです。
• その後SqlBulkCopyは、パフォーマンスのボトルネックの大部分はSqlBulkCopy.WriteToServerに直接あるサーバー
に

を書き込みます。私がユニットテストを行う場合には、WriteToServerだけを除いて、約1分でプロセスが戻ります。 WriteToServerはさらに15分以上かかる。単体テストの場合、ローカルマシン上にあるので、データベースが同じドライブ上にあるため、ネットワークを介してデータをコピーする必要はありません。

ヒープテーブルを使用しています（インデックスはありません、クラスター化されているか、クラスター化されていない、パフォーマンスに大きな違いはなく、さまざまなバッチサイズで使用しています）。

負荷時間を減らす必要があるので、誰かが今このターンアップからもう少し血を絞る方法を望んでいると思っています。

Answer 1

なぜSSISを直接使用しないのですか？

とにかく、あなたがIDataReaderへの解析から逃れた場合、あなたはすでに正しい道にいるのです。 SqlBulkCopy自体を最適化するには、フォーカスをSQL Serverに変更する必要があります。キーは最小限の操作で記録されます。これらのMSDN記事を読む必要があります：

• Prerequisites for Minimal Logging in Bulk Import
• Optimizing Bulk Import Performance。

あなたのターゲットはBツリー（つまり、クラスタ化インデックス付きテーブル）パフォーマンスの一括挿入、すなわち、ソートされた入力行セットの最も重要な教義の残念なものである場合、宣言することはできません。これはシンプルなので、ADO.Net SqlClientにはSSPROP_FASTLOADOPTIONS -> ORDER(Column)（OleDb）に相当するものはありません。エンジンはデータが既にソートされていることを知らないので、ソート演算子をプランに追加します。こぼれないように、小さなバッチサイズ（〜10k）を使用してください。私のオリジナルポイントを参照してください：これらはすべてOleDB MSDN仕様を掘り下げるのではなく、options and clicks to set in SSISです。

データストリームのソートが未開始か、デスティネーションがヒープの場合は、上記のポイントはミュートです。

しかし、最小限のロギングを達成することは、まともなパフォーマンスのためにはまだ必要です。