いくつかのテーブルでデータ管理プロセス (データのアーカイブ化) を改善するタスクを割り当てられました。テーブルは 200 GB のようです。
テーブルのパーティション分割とベストプラクティスについて読んでいますが、今知っている限り、プロセスは次のようになります
- ファイル グループとファイルを作成する
- パーティショニング関数を作成する
- パーティショニング スキーム - (間隔を適切なファイル グループにマップします)
- クラスター化インデックスを再作成します - これは、テーブルが物理的に別のファイルに移動された瞬間です
- 利益 ：）
しかし、この時点で既存の非クラスター化インデックスで何が起こっているのか、1 つの情報を見つけることができません。ここから：http://technet.microsoft.com/en-us/library/ms187526(v=sql.105).aspx 私が見つけた
パーティション化されたインデックスは、ベース テーブルとは別に実装できますが、通常は、パーティション化されたテーブルを設計してからテーブルにインデックスを作成するのが理にかなっています。これを行うと、SQL Server はテーブルと同じパーティション スキームとパーティション列を使用して、インデックスを自動的にパーティション分割します。その結果、インデックスは基本的にテーブルと同じ方法でパーティション化されます。これにより、インデックスがテーブルに揃えられます。
そしてもう一つ
一意の非クラスター化インデックスをパーティション分割する場合、インデックス キーにはパーティション分割列が含まれている必要があります。一意でない非クラスター化インデックスをパーティション分割する場合、SQL Server は既定でパーティション分割列をインデックスの非キー (含まれる) 列として追加し、インデックスがベース テーブルと一致するようにします。パーティション分割列がインデックスに既に存在する場合、SQL Server はその列をインデックスに追加しません。
しかし、これは私の問題を参照していませんが、定義にパーティション列がある/ない既存の非クラスター化インデックスに対して明示的にパーティション関数を作成する必要がありますか?
次のようなテーブルがあるとしましょう
テーブル A - col1 col2 col3
col1 にクラスター化されたインデックスを使用し、プライマリ パーティションの col3 にクラスター化されていない
パーティション分割後に col3 の非クラスター化インデックスで何が起こるか、それはテーブルと整列するのか、それとも PRIMARY パーティションに存在するのか