大量（8400万行）のデータを効率的に転送

約8400万行あります。それらのすべてを同じサーバー上の別のデータベースに転送する必要があるので、ソースデータベースから約6000万行を削除するために削除します。

8,400万行はすべて同じテーブルにあります。そのテーブルだけでデータベース全体の90％を占めています。

つまり...ソース：8,400万行-> 2,400万行宛先：0行-> 8,400万行

ソースは完全復旧モードを実行しており、デスティネーションは単純に実行されます。

これを行う最も効率的な方法は何でしょうか？

プランA：

1）挿入先に選択SELECT * FROMソース

2）切り捨てソース

3）ソースSELECT * FROM宛先WHERE keep_condition = 1に挿入

次の手段：

1）ソースデータベースのバックアップを宛先データベースとして復元します

2）宛先データベースで必要なテーブルを除くすべてのテーブルを削除します

3）TRUNCATEソース

4）INSERT INTO source SELECT * FROM destination WHERE keep_condition = 1に挿入します

プランC：

1）挿入先に選択SELECT * FROMソース

2）DELETEソースWHERE keep_condition = 0

または、他の何か？

ありがとう

私は、あなたがこれにアプローチすることを決定したとしても、これらのトランザクションをバッチ処理する必要があると付け加えます。最近、リンクされた記事で非常に幸運に恵まれており、私が目にするほとんどのバッチ処理ソリューションとは対照的に、インデックスを活用する方法に感謝しています。

最小限のログであっても、これらは大きなトランザクションであり、異常なログの増加（VLF、切り捨て、適切なサイズなど）の影響に対処するために多くの時間を費やす可能性があります。

ありがとう

「効率的」は、ログファイルの使用状況、I / Oパフォーマンス、CPU時間、または実行時間に適用できます。

ロギングの観点からはかなり効率的な、最小限のロギング操作を実現しようとします。これにより、ボーナスとして実行時間を節約できます。tempdbスペースがある場合は、次の方法が効果的です。

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

最小限のログが記録される操作を行うには、現在実行中のバックアップがないこと、データベースがBULK_LOGGEDリカバリモードに設定されていること、インデックスによってはターゲットテーブルが空である必要があるなど、いくつかの条件が満たされている必要があります。この動作の一部は、SQL Server 2005から2008に変更（改善）されました。

次に、テーブルとデータの詳細を知らなくても、他のオプションの方がパフォーマンスが良い場合があります。使ってみてください

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

..どれが最も効果的かを確認してください。

編集：一括ログ操作を実行するときは、ポイントインタイムリストア機能が必要であり、他のアクティビティがETLジョブが実行されているのと同時に。

私は少し前に最小限のログに記録された操作に関するブログ投稿を書きましたが、そこには他の投稿やドキュメントへのリンクがあります。

なぜBCPではないのですか？

1. sourcedbをバックアップする
2. sourcedbを一括ログに変更する

3. コマンドプロンプトを開く

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. データを確認する

8. SSMSからsourcedbテーブルを切り捨てます
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. sourcedbをフルに戻す

の前後にデータベース全体のバックアップまたはt-logバックアップのいずれかを使用せずに復旧モデルを変更することを推奨する必要があるとは思わないでください。BULK_LOGGED復旧モデルの機能の1つは、一括ログに記録された操作を含むtログのポイントインタイムリカバリを実行できなくなることです。クラシックシナリオ：毎晩の完全バックアップ、毎時のtログバックアップ。復旧モデルを一括ログに変更して、操作を開始します。何かがうまくいかず、トランザクションがロールバックします（または、トランザクションを使用していません）。ただし、データベースで他に何が起こっているのかわからないため、既知の適切なポイントに復元する必要があります。

いつ復元できますか？一括ログに記録された操作を含まない最後の1時間ごとのt-logバックアップ。n分のトランザクションを失う可能性があります。復旧モデルを変更する前の完全バックアップまたはt-logバックアップは、フォールバックポイントを作成します。どちらを選択するかは、RTOによって異なります。

テーブルからパーティションを削除することは、テーブルから大きなデータチャンクを削除するための非常に高速でリソース効率の良い方法です。このテーブルがソースと宛先の分割をサポートする方法でパーティション分割されていたとしたら、コピーを復元し、宛先から冗長テーブルと冗長パーティションを削除し、ソースから補完パーティションを削除することになります。

ただし、パーティショニングを有効にするコストにより、これは全体としてより高価な操作になる可能性があります。