BLOBデータのBCPパフォーマンスの最適化

私は、2TBデータベースのパーティションテーブルへのライブマイグレーションを計画するプロセスです。システムは広範に言えばドキュメントストアであり、スペースの大部分は50kbから500kbのLOBに割り当てられ、500kbから1MBの範囲の小さな割合です。移行の一部には、古いデータベースから新しいデータベースへのBCPデータが含まれます。

データの現在/過去の区分により、最終的な切り替えに先立って（静かな期間中に）段階的に古いデータを抽出し、稼働中のシステムへの影響を最小限に抑えることができるため、BCPが好ましいアプローチです。データ量とストレージの可用性により、パーティションスキームへのその場での再構築が不可能になります。

BLOBの内容により、ROWS_PER_BATCHではなくKILOBYTES_PER_BATCHを試してみると、パフォーマンスがいくらか向上するのではないかと思われます。BCPドキュメントでは、SQLがこの値に基づいて操作を最適化できることが提案されています。

私が見つけることができないのは、これらの最適化の性質やテストを開始する場所に関するガイダンスです。提案がなければ、4/8/16/32 / 64mbの境界で短いランを開始してみます。

おそらくパケットサイズを変更することでいくらかの利点が得られます（サーバーレベルの設定ではなく、BCP -aパラメーター）。より一般的なアプローチがない限り、これを最大65535に上げる傾向があります。

これはあなたの質問への直接の答えではありませんが、それらを読むことから利益を得るいくつかの記事があります（最初にそれらを見つけられなかった場合のために:-)）。それらは、bcp / bulkコピーを使用して大量のデータをロードすることについてです。私はそれらをすべて読みましたが、KILOBYTES_PER_BATCHに関する詳細は何も見つかりませんでした。それらはすべてROWS_PER_BATCHを使用していますが、他の有用な情報はきっと見つかるでしょう。

• 1 TB未満で1 TBをロード（SQL CATチームから）-ここからのアドバイスのリスト（引用）：

  • 使用可能なCPUと同じ数のロードプロセスを実行します。32個のCPUがある場合、32個の並列ロードを実行します。8つのCPUがある場合、8つの並列ロードを実行します。
  • 入力ファイルの作成を制御できる場合は、並列で実行するロードスレッドの数で均等に分割できるサイズにします。また、スイッチパーティション戦略を使用する場合は、すべてのレコードが1つのパーティションに属していることを確認してください。
  • SQL Serverマシンでプロセスを実行している場合は、BCPではなくBULK insertを使用します。
  • テーブルパーティショニングを使用して、さらに8〜10％増加します。ただし、入力ファイルがパーティショニング機能に一致するように保証されている場合のみです。つまり、1つのファイルのすべてのレコードが同じパーティションにある必要があります。
  • TABLOCKを使用して、一度に行をロックしないようにします。
  • 1つのテーブルに複数のストリームをインポートする場合は、バッチごとのROWS = 2500、またはこれに近い値を使用します。

• 大規模なリレーショナルデータウェアハウスを構築するためのトップ10ベストプラクティス（SQL CATチームから）-アドバイス（引用）：

  • 初期データのロード中に、SIMPLEまたはBULK LOGGED復旧モデルを使用します。
  • クラスター化インデックスを使用して、パーティション化されたファクトテーブルを作成します。
  • 各パーティションにインデックスなしのステージングテーブルを作成し、各パーティションにデータを入力するためのソースデータファイルを個別に作成します。
  • ステージングテーブルに並行してデータを入力します（複数のBULK INSERT、BCP、またはSSISタスクを使用します）
  • 各ステージングテーブルにクラスター化インデックスを構築し、適切なCHECK制約を作成します。
  • すべてのパーティションをパーティションテーブルに切り替えます。
  • パーティションテーブルに非クラスター化インデックスを構築します。

• データロードパフォーマンスガイド（SQL CATチームより）

• パーティション分割されたテーブルへのバルクデータの読み込み -SQL Serverベストプラクティスの記事（Technetの記事）

• SQL Server 2000のインクリメンタルバルクロードのケーススタディ（Technetの記事）

• 大規模なFast-Track POCからの教訓と発見（SQL CATチームから）

• SQL Server BCPのパフォーマンスチューニングのヒント（Brad McGehee著）

• パフォーマンスへの影響：最適なバッチサイズを見つける（Linchi Shea著）

および明白なMSDNリファレンス：

• 一括インポート用のバッチの管理
• 一括コピーのバッチサイズの管理
• 一括コピーのパフォーマンスに関する考慮事項
• 一括インポートを最適化するためのガイドライン
• 一括インポートのパフォーマンスの最適化

私の経験では、並列ロードと複数のバッチサイズでのテストを使用して、高速データロードを実現することに成功しました。個人的なテストのみがあなたに合っていると思います。参考文献にいくつかの良いアドバイスがあることを願っています。