シナリオ:
このプロセスは遅く、多くのリソースを消費するので、私はこのプロセスを取り除きたいと思います。日付列にパーティション関数を使用してDB_Aにテーブルパーティションを実装し、すべてのレコードを1つのパーティションに2か月未満、すべてのレコードを別のパーティションに2か月以上保存することを考えています。私の質問:
パーティショニングを使用すると、1日あたりのパーティションを作成する必要があります。これにより、Pre-SQL 2012の制限である1000パーティションは、3年間のアーカイブしか許可されないため、新しい見方ができます。 SQL Server 2012を使用すると、1日に1つのパーティションで十分な15000のパーティションを取得できます。
毎日、新しいパーティションを追加します。過去61日のパーティションを移動する場合、効率的に実行できますが、それでもオフライン操作です。 パーティションを別のファイルグループに効率的に移動する を参照してください。
すべてのインデックスを調整する必要があります。 パーティションインデックスの特別なガイドライン を参照してください。
パーティショニングを購入するのは簡単な決定ではなく、かみ砕くことはかなり大きなバイトになるかもしれません...参照 テーブルパーティショニングを使用するかどうかを決定する方法 を参照してください。特に、パーティショニングによるパフォーマンスの向上は期待できません。日時でクラスタリングすることにより、時系列のパフォーマンスの問題に取り組む必要があります。
パーティション関数が動的であるかどうかはわかりませんが、疑問です。そのルートに行かずにあなたのためのいくつかのオプション:
1-カレンダーDATEでパーティション分割し、毎日最も古いパーティションから移動します
2-日付でフィルタリングするビューを作成し、既存のすべてのクエリをそこにポイントします(これは、基になるテーブルの名前を別のものに変更し、ビューに現在のテーブルの名前と同じ名前を付けることで簡単に管理できます)。これは、インデックスの変更でも最適化できます。
上記の最初のオプションは、クエリで日付フィールドを使用する場合、LOTがより適切に機能することを覚えておいてください。そうでない場合でも、現在のプロセスよりは高速ですが、クエリの大幅な改善はありません。パーティション化は一般に、パーティションフィールドでフィルタリングでき、オプティマイザがどのパーティションを参照するかを知っている場合に最も効果的に機能します。
DB_A-過去60日ごとに異なるパーティションを持つtableA-最も古いパーティションからデータを移動するためのstagingTable
DB_Archive tableA-60日より古いすべてのデータを格納します。 (分割されていません)
プロセス:1. 1日の終わりの前:パーティション機能の変更-範囲を分割して、新しい日の新しいパーティションを追加します。 (注:「今日の日付+ 1日」のパーティションを作成する代わりに、数ステップ先にしたい場合があります。例:「今日の日付+ 5日」
毎日の終了後、最初にDB_A.tableAの最も古いパーティションをDB_A.stagingTableに切り替えます。最も古いパーティションをマージします。
DB_A.stagingTableからDB_Archive.tableAにデータをインポートします。最後にDB_A.stagingTableを切り捨てます
上記はローリングウィンドウと呼ばれ、VLDBのかなり一般的なシナリオです。パーティション分割については、Microsoftが提供するこのホワイトペーパーを参照してください: パーティションテーブルとインデックス戦略 または スライドウィンドウシナリオ
SQL Serverでデータをアーカイブおよびパージする動的なアプローチを使用できます。以下のリンクに従ってください。
http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html