現在使用されているツールはInformaticaであり、クラスター化インデックスを削除してデータベースに追加するブックエンドストアドプロシージャがあります。クラスタ化インデックスを追加し直すストアドプロシージャでは、インデックスのDDLがストアドプロシージャにハードコードされています（Microsoftがsysテーブルを変更してそこから再生成することを恐れて悪いインデックスが作成されるため、sysテーブルは使用しません。失敗します）。これにより、ユーザーがクラスター化インデックスを作成したが、ストアドプロシージャを更新しようとは思わず、次にバルクが発生したときにこれらのインデックスが失われるという問題が発生します。以前はすべてのインデックスに対してこれを実行しましたが、非クラスター化インデックスを無効化/再構築の使用に切り替えました。ただし、これがクラスター化されたインデックスに対して行われると、本質的にテーブルであるため、テーブルに挿入できなくなるため、これはオプションではありません。
パフォーマンスは重要ですが、すべてではありません。優れたパフォーマンスと簡単な保守性は、優れたパフォーマンスと複雑な保守性よりも優れています。
多くのサイトを読んだ後、一括挿入を実行するときに、主キーと同じ順序ではないデータに対して、ヒープに挿入し、後でpkを適用する方が高速であることにほぼ普遍的に同意しています（http://msdn.microsoft.com/en -us / library / ms177445.aspx 、http： //msdn.microsoft.com/en-us/library/dd425070（v = sql.100）.aspx ）。これらのサイトのほとんどは、組織やツールセットでは使用できないことを前提としています。
現在、現在の標準ポリシーにより、完全復旧モデルを使用する必要があるため、ヒープとクラスター化インデックスを参照してどの選択を行っても、最小限のロギングは発生しません。
Informaticaの管理者によると、bcpでタブロックまたは注文ヒントを指定することはUIを介して不可能であり、組織は保守性のためにUI以外のカスタマイズに不利です。
したがって、このすべての後の質問は、上記のすべての要因を考慮して、信頼性の低いストアドプロシージャを続行するか、クラスター化インデックスに挿入するか、3番目に優れたソリューションを使用することをお勧めします。また、この項目に類似した他のスタックの質問があることも認識していますが、それらは具体的にバルクに対処しておらず、および/または回答で同様の仮定を行っていません。