ステージングデータのDROP vs DELETE vs TRUNCATE

Question

MS-SQL-Serverにデータ（>> 1 GB）をインポートする必要があります。いくつかの理由で、このデータをステージングテーブルにインポートする必要があります（ターゲットに直接インポートするのではありません）。ステージングから、データがターゲットテーブルにロードされます。ステージングテーブルのデータは二度と使用されません。私にはいくつかの方法があります：

データをステージングステーブルにロードし、このデータを新規としてマークし、マークされたデータのみをターゲットのマークされていないデータにロードします。
ステージング内のすべてのデータを削除し、データをステージングテーブルに読み込み、すべてのデータをターゲットに読み込みます。
ステージングテーブルのトランケート、ステージングへのロード、ターゲットへのロード
ステージングテーブルをドロップし、ステージングテーブルを作成し、ステージングテーブルにロードし、ターゲットにロードします。
ステージングデータベースを削除し、ステージングテーブルを作成し、ステージングテーブルにロードし、ターゲットにロードします。

ソリューションがサーバーの役割によって制限されていない場合：推奨されるソリューションは何ですか？最も堅牢なのはどれですか？

データが不要になった場合、解決策1はおそらくナンセンスです。ソリューション3のパフォーマンスは1と2に比べてはるかに優れていますが、ソリューション4と3の間のパフォーマンスはどうですか？実際には、ロードプロシージャ内のステージングプロセス内のすべてのパラメーターを変更できるので、ソリューション5を選択しますが、データベースを削除して作成する権限が必要です。これは、ロードプロセスではかなり多くなります。したがって、ほとんどの場合、ドロップを使用してステージングテーブルを再作成します。しかし、これは推奨される方法ですか？

Kin Shah · Accepted Answer

推奨される解決策は何ですか？

オプション3は、他に挿入するデータベースの復旧モデルを変更できる場合は、ステージングデータベースを作成して、一括または単純復旧します。
SQL Serverのバージョンによっては、schema_ONLYで作成されたステージングにメモリ最適化テーブルを使用することもできます。

最も堅牢なのはどれですか？ -要件に合ったものをテストします。 dbやテーブル全体を削除しないでください-とにかくそれを再利用しているときに、削除して再作成するポイントは何ですか。

最近、3 GB以上のcsvファイルをSQLサーバーにインポートする必要がありました。以下は、物理マシンで10万行/秒（ハードウェアと環境の違いによるYMMV）を達成するために（SSDと16コアと256GB RAMを使用するVM）では少し少なかった）。

一括ログ復旧モデルで BULK INSERT .. WITH（TABLOCK）＆TF 610＆適切なバッチサイズを使用し、ステージングテーブルにデータを挿入する（インデックスなし）または SSIS-高速に使用）ロード。
圧縮用のsqlサーバーのバージョンに応じて、列ストアインデックスを使用できます（少し遅くなる可能性がありますが、それほどではありません）。
最高のパフォーマンスを得るには、ファイルを分割し、BULK INSERTを使用して同時に挿入します。
挿入しようとしているDBの一括ログモデルまたは単純復旧モデルに切り替えることができない場合は、ステージングテーブルを備えた別のデータベースを使用できます。
データが大きくなる場合は、別のパーティションに挿入し、パーティション化を使用して、ロードが完了したらパーティションを切り替えます。 SQL Server 2016以降では、個々のパーティションを切り捨てることができます。このように、BULK INSERTを使用して異なるパーティションに挿入してからパーティションを切り替える動的スクリプトを作成できます。
自動成長イベントが最小限になるようにデータファイルとログファイルのサイズを事前に設定し、電源プランを高パフォーマンスに設定し、ファイルの即時初期化を有効にします。

その他のヒントについては、私の回答を参照してください。

SSISまたは一括挿入

Tony Hinkle · Answer

「推奨される方法」は、関連する要素を考慮して最適なソリューションを設計することです。

オプション＃1と＃2は、不要なI/Oを大量に発生させるため、理想的とは言えません。＃3は何がベストか最も状況ですが、I/Oに関する限り、それは＃4と大差ありません。したがって、パフォーマンスに関しては、＃3と＃4は同じであると考えることができます。テーブルを単に切り捨てるのではなく、テーブルを削除または作成するための追加のI/Oは、一般的なデータロードのI/Oと比較して重要ではありません。

あなたのコメントは、ステージングテーブルを頻繁に変更する必要があることを示しているようです。その場合は、＃4が最適です。これはステージングテーブルであるため、アクセス許可が複雑になることはほとんどありません。ステージングアカウントが読み取り/書き込み可能な唯一のIDである専用のステージングデータベース内にある場合は、テーブルが許可されているときにアクセス許可を明示的に設定する必要もありません。作成した。

オプション＃5は、毎回新しいデータベースを作成する特別な理由がない限り、重要ではありません。