データをアーカイブするためのテーブルパーティション

13

シナリオ：

  • 2つのデータベース：DB_AとDB_Archive、tableAと呼ばれる非常に大きなテーブル1つ。
  • 過去2か月のレコードに対してtableAがDB_Aで頻繁にクエリされるため、60日を超えるレコードは毎日DB_Aから削除され、主にDB_Archiveに移動されて「分離」されます。

このプロセスは時間がかかり、多くのリソースを消費するため、このプロセスを削除します。日付列のパーティション関数を使用してDB_Aにテーブルパーティションを実装し、1つのパーティションに2か月未満のすべてのレコードと別のパーティションに2か月以上のすべてのレコードを格納することを考えています。私の質問：

  • このシナリオは、2つの異なるデータベースがある場合のように動作しますか？tableAにレコードを照会する> getdate（）-30、アーカイブパーティションを読み取りますか？
  • インデックスもパーティション化する必要があると思いましたか？
  • 明日パーティション関数が「変更」されるという事実にどう対処しますか、つまり、今日関数を作成した場合（7月2日、その範囲は5月2日ですが、明日は5月3日です）。動的パーティション関数を作成できますか？
sql-server  sql-server-2005  partitioning 
— ディエゴ
ソース
動的関数は許可されていても良い考えだとは思いません（そうではないと思います）...すぐに詳細を知ることができますが、おそらくカレンダーの日付に基づいてパーティションを切り、移動する必要があると思います一度に1つのパーティション...しかし、ここにはさまざまなオプションがあります。
— JNK
去年あなたがしたいことの線に沿って例をスクリプト化しました。x日分のデータを高速（高価な）アレイに保持し、アーカイブデータをより安価なストレージに移動したいという特殊なケースでした。サンプルスクリプトをサニタイズできる場合は投稿します。それ以外の場合は、プロセスの要約になります。
— マークストーリースミス
こんにちはマーク、はい、してください、あなたもあなたの経験を共有できる場合。成功しましたか？
— ディエゴ
それは機能しますが、最終的には不要でした（より単純なルートを取りました）。おそらく、あなたのケースに60日間の境界が存在する理由を拡張できますか？誰もが正しい方向にあなたを指すのに役立ちます。
— マークストーリースミス

回答:

6

パーティショニングを使用すると、1日にパーティションを作成する必要があります。これにより、3年のアーカイブしか許可されないため、SQL-2012のPre-SQLの制限が新しいパースペクティブになります。SQL Server 2012では、1日に1パーティションで十分な15000パーティションを取得できます。

毎日新しいパーティションを追加します。過去61日のパーティションを移動したい場合は効率的に実行できますが、それでもオフライン操作です。別のファイルグループへのパーティションの効率的な移動を参照してください。

すべてのインデックスを揃える必要があります。パーティションインデックスの特別なガイドラインを参照してください。

パーティション分割を購入するのは簡単な決断ではなく、噛むのはかなり難しいかもしれません... テーブル分割を使用すべきかどうかを判断する方法を参照してください。特に、パーティショニングによるパフォーマンスの向上は期待できません。日時でクラスタリングすることにより、時系列のパフォーマンスの問題に対処する必要があります。

— レムス・ルサヌ
ソース
新しい制限は、2008 SP2および2008 R2 SP1で使用可能です。blogs.msdn.com/b/hanspo/archive/2010/11/29/...
— ジョン・シーゲル
@Jon：2008 SP2、2008R2 SP1の実装には大きな警告 が付いています. As explained in this white paper, there are implications on certain features, including performance.。SQL 2012サポートには警告はありません。
— レムスルサヌ
それを指摘してくれてありがとう。2008/2008 R2で使用するにはいくつかの注意事項があることは事実ですが、必要に応じて使用可能なオプションです。
— ジョンセイゲル
ご意見をありがとうございます。後で素材のコメントを読みます
— ディエゴ
2

パーティション関数が動的であるかどうかはわかりませんが、疑いがあります。そのルートに行かずにあなたのためのいくつかのオプション：

1-カレンダーDATEにパーティション分割し、毎日最も古いパーティションから移動する

2-日付でフィルターするビューを作成し、既存のクエリをすべてポイントします（これは、基になるテーブルの名前を別の名前に変更し、現在のテーブルの名前をビューに指定することで簡単に管理できます）。これは、インデックスの変更によっても最適化できます。

上記の最初のオプションは、クエリで日付フィールドを使用する場合、LOTの方がうまく機能することに注意してください。そうしないと、現在のプロセスよりも高速になりますが、クエリに大きな改善はありません。パーティションフィールドでフィルタリングでき、オプティマイザーがどのパーティションを調べるべきかを知っている場合、パーティションは一般的に最適に機能します。

— JNK
ソース
「毎日」の手動操作を避けたい
— ディエゴ
2

動作するものは次のとおりです。DB_A-過去60日間のそれぞれに異なるパーティションを持つtableA-最も古いパーティションからデータを移動するためのstagingTable

DB_Archive tableA-60日より古いすべてのデータを格納します。（分割されていない）

プロセス：1.一日の終わり前：パーティション機能の変更-範囲を分割して、新しい日に新しいパーティションを追加します。（注：「今日の日付+ 1日」のパーティションを作成する代わりに、数ステップ先に進みたい場合があります。例：「今日の日付+ 5日」

  1. 毎日の終了後、最初にDB_A.tableAの最も古いパーティションをDB_A.stagingTableに切り替えます。最も古いパーティションをマージします。

  2. DB_A.stagingTableからDB_Archive.tableAにデータをインポートします。最後にDB_A.stagingTableを切り捨てます

上記はローリングウィンドウと呼ばれ、VLDBの非常に一般的なシナリオです。分割にMicrosoftがこのホワイトペーパーを参照してください：パーティションテーブルとインデックスの戦略をまたは上でこれを具体的にしてみてくださいウィンドウシナリオをスライディング

— ダルメンダール・クマール「DK」
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.