0

パーティション スキーマの一部である DATETIME フィールドを持つ非常に大きなテーブル (800GB) があります。このフィールドの名前は tran_date です。私が抱えている問題は、インデックスがパーティションに適切に配置されておらず、NULL 可能に設定されているため、PRIMARY KEY に tran_date フィールドを含めることができないことです。

すべての外部キー関係、統計、およびインデックスを削除できますが、パーティション スキーマがまだ tran_date 列に依存しているため、列を変更できません。

私の調査では、パーティションからテーブルを移動する 1 つの方法を見つけました。これは、クラスター化インデックスを削除し、クラスター化インデックスを PRIMARY ファイル グループに再書き込みして、列を変更できるようにしますが、この操作には時間がかかります。ドロップするのに数時間、一時的な CLUSTERED INDEX を PRIMARY に書き込むのに 13 時間かかり、それをドロップしてテーブルを変更し、CLUSTERED INDEX を適切に書き直す必要があり、さらに 13 時間かかります。さらに、複数のテーブルがあります。

開発環境で同様のサイズのデータ​​ セットを使用してこの展開をテストしたところ、完了するまでに数日かかったので、今回は削減する方法を探しています。

PRIMARY に CLUSTERED INDEX を書き込むことなくテーブルをパーティションから移動できれば、列の変更に必要な時間が大幅に短縮されます。

4

1 に答える 1

1

いずれにせよ、データを「ポイント A」(データベース内のテーブル パーティションに格納されている) から「ポイント B」(データベース内のテーブル パーティションに格納されていない) に移動することになります。目標は、回数を最小限に抑えることです。これを行う最も簡単な方法は次のとおりです。

  • 新しい非パーティション テーブルを作成する
  • そのテーブルにデータをコピーします
  • 元のテーブルをドロップ
  • 新しいテーブルの名前を適切な名前に変更します

対処すべき問題の 1 つは、クラスター化インデックスです。クラスター化インデックスなしで新しいテーブルを作成し、データをコピーしてからインデックスを再作成する (余分な時間と手間がかかる) か、クラスター化インデックスを使用してテーブルを作成し、データを「順番に」コピーすることができます (たとえば、低い ID から高い ID へ）。これは、クラスター化されていないテーブルにコピーするよりも遅くなりますが、クラスター化されたインデックスを構築する必要がないため、全体的には高速になる可能性があります。

もちろん、「コピーしている途中で変更されたらどうしよう」という問題はありますが、テーブルの分割はウェアハウジングを意味するので、気にしなくてもいいのではないでしょうか。

最後に、データのゴブをコピーするときは、トランザクション ログが肥大化しないように、挿入を複数の挿入に分割することをお勧めします。

于 2011-08-23T15:33:17.170 に答える