SQL Server 2008-パーティション化とクラスター化インデックス

ですから、私のdb設計を完​​全に制御することはできません。そのため、このシナリオの目的のために現在のシステムの多くの側面を変更することはできません。

デザインの側面をどのように再考すべきかについてのコメントはおそらく正しいが、役に立たない:)

私は非常に大きなテーブルがあり、幅が約150フィールド、行が約600mあり、多数のプロセスを駆動します。これはデータウェアハウスの状況にあるため、スケジュールされたロードプロセス以外では更新/挿入が行われないため、インデックスが大量に作成されます。

このテーブルをパーティション分割しようとする決定が下されており、パーティション分割されたテーブルのインデックス作成に関して懸念があります。私はパーティション分割の経験がないので、入力やリンクを歓迎します。私はBOLまたはmsdnで私が特に望んでいるものを見つけることができませんでした。

現在IncidentKey、varchar(50)一意であるとは呼ばないフィールドにクラスターを作成します。1〜100個の同じレコードを持つことができますIK（コメントは不要です）。古いIncidentKeyレコードで新しいデータを取得することが多いため、どちらもシーケンシャルではありません。

IncidentDateパーティションが正しく機能するためには、パーティション化フィールドをクラスター化インデックスキーに含める必要があることを理解しています。そうなると思っていますIncidentKey, IncidentDate。

問題は、「新しい」パーティションのレコードがクラスター化インデックスの「古い」パーティションのレコードの前にある場合、クラスター化インデックスの仕組みはパーティションテーブルの2パートキーでどのように機能するかです。

たとえば、5つのレコードがあります。

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

新しいレコードを取得する場合ABC123, 2/1/2011は、クラスター化インデックスのBEFORE にある必要がありXYZ999, 1/1/2010ます。これはどのように作動しますか？

断片化とポインターを想定していますが、デュアルパートキーを持つパーティションテーブルの非パーティションクラスター化インデックスの物理ストレージと構成に関する情報が見つかりません。

パーティション化されたテーブルは、実際には個々のテーブルをつなぎ合わせたコレクションのようなものです。たとえば、によるクラスタリングIncidentKeyとパーティション分割の例ではIncidentDate、パーティション化機能がテーブルを2つのパーティションに分割し、1/1/2010がパーティション1に、7/1/2010がパーティション2になります。データはディスク上に次のようにレイアウトされます。

Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

低レベルでは、実際には2つの異なる行セットがあります。すべての行セットをまとめてシーク、スキャン、および更新するプランを1つとして作成することにより、単一のテーブルのような錯覚を与えるクエリプロセッサです。

非クラスター化インデックスの行には、対応するクラスター化インデックスキーがあります（例：）ABC123,7/1/2010。クラスター化インデックスキーには常にパーティション化キー列が含まれているため、エンジンはクラスター化インデックスのどのパーティション（行セット）でこの値（この場合、パーティション2）を検索するかを常に認識します。

パーティション化を扱うときはいつでも、NCインデックスが整列されるか（NCインデックスがクラスター化インデックスとまったく同じようにパーティション化される）、非整列化されるか（NCインデックスは非パーティション化、またはクラスター化インデックスとは異なるパーティション化）を考慮する必要があります。非境界整列インデックスはより柔軟性がありますが、いくつかの欠点があります。

• 非境界整列インデックスは、特定のクエリプランに大量のメモリを必要とします
• 非整列インデックスは、効率的なパーティション切り替え操作を妨げます

アライメントされたインデックスを使用するとこれらの問題は解決しますが、この物理的なストレージ設計オプションがデータモデルに波及するため、独自の問題が発生します。

• 位置合わせされたインデックスは、一意の制約を作成/実施できなくなることを意味します（パーティション列を除く）
• パーティション化されたテーブルを参照するすべての外部キーには、リレーションにパーティション化キーが含まれている必要があります（パーティション化キーはすべてのインデックスに配置されるため）。また、パーティション化されたテーブルを参照するすべてのテーブルにパーティション化キー列の値が含まれている必要があります。Orders-> OrderDetailsを考えてください。OrdersがOrderIDであるがOrderDateでパーティション化されている場合、OrderDetailsにはOrderIDだけでなくOrderDate も含まれて、外部キー制約を適切に宣言する必要があります。

これらの影響は、パーティション化を展開するプロジェクトの開始時にめったに呼び出されませんでしたが、存在し、深刻な結果をもたらします。

アライメントされたインデックスがまれまたは極端な場合だと思う場合は、これを考慮してください。多くの場合、ETLおよびパーティション化ソリューションの基礎はステージングテーブルの高速切り替えです。切り替え操作には、整合インデックスが必要です。

ああ、もう1つ：外部キーに関する他の議論と、パーティション化列の値​​を他のテーブルに追加することの波及効果は、joinsにも等しく適用されます。

クラスター化インデックスに複数のパーティションがある場合、各パーティションには、その特定のパーティションのデータを含むBツリー構造があります。たとえば、クラスター化インデックスに4つのパーティションがある場合、4つのBツリー構造があります。各パーティションに1つ。参照 クラスター化インデックス構造

パーティション索引の特別なガイドライン

パーティションインデックスの特定のパーティションを再構築できます。

例えば

ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO