SQLのデータの一部をバックアップする

Question

私は数十億のレコードを含む巨大なスキーマを持っています。私は13ヶ月以上古いデータをパージし、必要なときにいつでも回復できるようにバックアップとして保持したいと思います。

これはSQLで行う最良の方法ですが、このスキーマの別のコピーを作成し、すべてのテーブルに削除トリガを追加すると、トリガが発生したときにパージされたデータがこの新しいスキーマに挿入されます。

トリガーを使用する場合、削除ステートメントごとに1つのレコードしか存在しませんか？またはすべてのレコードが挿入されますか？ 何とかバルクコピーを使用できますか？

Answer 1

トリガーは必要ありません。毎日実行しているジョブを使用すると、古くなったデータがアーカイブテーブルに格納されます。

私が推測する最良の方法は、現在のスキーマのコピーを作成することです。主要部分では、アーカイブ部分で13カ月以上古いものをすべて削除します。最後の13カ月間にすべて削除します。

データを収集するSP（または任意のSP）を作成するよりも、それをアーカイブに入れてメインテーブルから削除するよりも簡単です。これを毎日の仕事に入れてください。

Answer 2

私は、これは、SQL Serverのストレッチデータベース機能のための完璧なユースケースであることをお勧め2016年

さらに詳しい情報：https://msdn.microsoft.com/en-gb/library/dn935011.aspx

寒データがなくても与えられた日付基準をクラウドに移動することができますデータベースを照会する際にアプリケーションまたはユーザーがそれを認識していることを示します。バックアップは不要で、セットアップも非常に簡単です。

Answer 3

これを行うには（月単位で）最もクリーンで最速の方法は、おそらく月ごとの日付列に基づいてパーティション表を作成することです。特定のパーティション内のデータを移動することはメタ操作であり、非常に高速です（パーティションの設定とその機能が適切に設定されている場合）。私はパーティション化を使用して300GBのテーブルを管理しており、非常に効果的です。各エッジの日付が正しく処理されるように、パーティション関数に注意してください。

いくつかの提案された解決策には、実行に長時間を要する何百万行もの削除が含まれています。プロファイラや拡張イベントを使用して、さまざまなソリューションをモデリングし、どれが最も効率的かを確認します。

Answer 4

私はトリガーを作成しないことに同意します。すべての挿入/更新/削除で非常に遅くなります。

データアーカイブストアドプロシージャを使用するのが最適かもしれません。

複数のデータベースの使用を検討してください。現在のデータを持つ現在のデータベース。次に、現在のデータベースからデータを移動する夜間または月間のストアドプロシージャプロセスの何らかの種類にレコードを移動するアーカイブまたは複数のアーカイブデータベース。

本番システムとまったく同じスキーマを使用できます。

データがすでにデータベースにある場合は、バルクコピーは不要です。そこからアーカイブデータベースをバックアップして、SQL Serverの外に置くことができます。必要に応じてデータベースを復元して、データを再び利用可能にします。これは、一括コピーよりもはるかに高速で管理が容易です。

Answer 5

MicrosoftのStretch DBに関するドキュメント（https://docs.microsoft.com/en-us/azure/sql-server-stretch-database/）によれば、コールドストレージに移行された行や移行対象の行は更新または削除できません。

したがって、Stretch DBはアーカイブのための有能な技術のように見えますが、SQL 2016の実装はアーカイブとパージをサポートしていないようです。