1

6 億件のレコードがあり、PS_TRPdate(TRPDate) 列のパーティションもあるテーブルがあり、それを別のパーティション PS_LPDate(LPDate) に変更したいと考えています。

そのため、次の手順で少量のデータを試しました。1) 主キー制約を削除します。2) 新しいパーティション PS_LPDate(LPDate) を使用して、新しい主キー クラスター化インデックスを追加します。

6億件のレコードで実現可能ですか? 誰でも私を案内してもらえますか？パーティション化されていないテーブルではどのように機能しますか?

--343

4

1 に答える 1

2

私の直感では、新しい主キー、ファイル グループ、およびファイルを使用して並列テーブルを作成する必要があります。

私の仮定をテストするために、最初の 500 万個の素数を 3 つのファイルまたはファイル グループに保存した古いブログ記事を調べました。

Kalen Delaneyが作成した TSQL ビューを使用し、標準に合わせて変更してパーティション情報を確認しました。

ご覧のとおり、主キーに基づいて 3 つのパーティションがあります。

ここに画像の説明を入力

次に、my_value 列に主キーをドロップし、chg_value という名前の新しい列を作成し、それを素数に更新してから、新しい主キーの作成を試みます。

-- drop primary key (pk)
alter table tbl_primes drop constraint [PK_TBL_PRIMES]

-- add new field for new pk
alter table tbl_primes add chg_value bigint not null default (0)

-- update new field
update tbl_primes set chg_value = my_value

-- try to add a new primary key
alter table tbl_primes add constraint [PK_TBL_PRIMES] primary key (chg_value)

まず、PK をドロップした後もパーティションが残っていることに驚きました。ただし、ビューには、インデックスが存在しないことが示されています。

ここに画像の説明を入力

次に、制約の作成中に次のエラーが表示されます。

ここに画像の説明を入力

パーティションをスキームの一部ではない 1 つのファイル グループにマージ/切り替え、主キー、パーティション関数、およびパーティション スキームを削除/作成し、適切なマージ/切り替えステートメントを使用してデータをもう一度移動することもできますが、いいえ。

これにより、大量の作業 (TSQL) が生成され、ディスク上で大量の I/O が発生します。

スペースがある場合は、新しい主キーを使用して並列パーティション テーブルを作成することをお勧めします。古いテーブルから新しいテーブルにデータを再ロードします。

データ圧縮を使用しておらず、エンタープライズ バージョンの SQL Server を使用している場合は、オンにしてバイト数を節約してください。

幸運を！

ジョン

www.craftydba.com

于 2013-09-03T19:56:57.910 に答える