単一のファイルグループでのパーティション分割
データベースに非常に大きなテーブルがいくつかありますが、このデータのかなりの部分が「古い」ものです。
私の制御が及ばない状況のため、この「古い」データを削除することは許可されていません。その他の制限は、データベースを変更できないことです。つまり、データベースにファイルグループを追加できます。現在の状態では、すべてがPRIMARYファイルグループに存在しています。
これらのテーブルを「新しい」、「古い」、「アーカイブされた」などのいくつかのパーティションに分割することを考えていました。この目的で使用したい「ステータス」列があります。
説明されているシナリオと制限を考えると、パーティション分割がここで意味をなすかどうか疑問に思っていました。言い換えると、テーブルがこのようにパーティション分割されているが、すべてのパーティションが同じファイルグループにある場合、SQL Serverは、「新しい」データが存在する基になるファイル内のその特別な領域を見つけるのに十分スマートであり、 「古い」データのあるエリア？
言い換えると、私のデータの80％が「古い」としましょう。 SQL Serverには、基になるファイルの100％へのアクセスを回避し、「新しい」データを含む20％のみにアクセスするメカニズムがありますか（もちろん、クエリのWHERE句でパーティション列を指定するとします）。 。
私はこれに答えると思います、パーティションが内部でどのように実装されているかを理解する必要があります。私はどんなポインタにも感謝します。
同じファイルグループ内のテーブルをパーティション分割することには、2つの利点があります。
- 大きなインデックスの一部を段階的に再構築できるため、より効率的なメンテナンスが可能になります。
ALTER INDEX [foo] REBUILD PARTITION=n詳細については。 - パーティションの排除と（場合によっては）パーティションレベルのロックを活用して、クエリのメンテナンスを改善します。 私のブログ でこれについて議論します。
パーティションを作成する場合は、いくつかの点に注意してください。
- テーブルにクラスター化インデックスがある場合（実際にそうでなければなりません）、パーティション化キーはクラスター化インデックスの一部である必要があります。
- パフォーマンスの問題を回避するには、パーティションを調整する必要があります。つまり、インクルードとして、またはインデックス自体の一部として、すべてのインデックスにパーティションキーを含める必要があります。
- SQL Serverの現在のバージョン（2005-2012）では、パーティションのインデックスの再構築はオフラインです。パーティションが大きく、パーティションごとに再構築すると、ブロッキングの問題が発生する可能性があります。
それを実装する前に、パーティション分割について徹底的に調査することをお勧めします。 Kendra Littleには 優れたリソースのリスト があり、そこから始めることができます。
答えは「はい」です。パーティションを定義するために使用されるロジックに基づいて入力をフィルタリングするメカニズムがクエリにあります。
ただし、適切なフィルターが必要です。そうしないと、すべてのパーティションがスキャンされます。これには通常、パーティションを選択するための日付フィルター（あなたの場合）が含まれます。
これを強制する1つの方法は、ビューに適切なロジックを使用して、1つのパーティションのみにアクセスするビューを用意することです。