3

最近、私は、ファイル グループを使用して設計されていない古いデータベースを再構築しようとしており (デフォルトのみPRIMARY)、とりわけ、一連のテーブルをDataSAN 上にある新しいファイル グループに移動しようとしています。データを移行する方法を知っています：

ALTER TABLE MyTable
DROP CONSTRAINT PK_MyTable WITH (MOVE TO [MyDB_Data])

ALTER TABLE MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY CLUSTERED (MyID)
ON [MyDB_Data]

しかし、これが私が今までにやらなければならなかった最も退屈な仕事ではない場合は気の毒です. そして、エラーが発生しやすいです。ある時点で、PK に値の列の 1 つを誤って含めてしまったことに気付く前に、30 GB のテーブルを移動する途中 (進行状況インジケーターがないためだと思います) でした。だから私は最初からやり直さなければなりませんでした。

テーブルに多くの依存関係がある場合はさらに悪化します。次に、主キーを削除することはできません。それを参照するすべての外部キーを削除して再作成する必要があります。これにより、何百行ものボイラープレートが発生します。テーブルを 100 倍すると、実に馬鹿げたものになります。手首が痛い。

誰かがこれのショートカットを思いついたことがありますか? それを実行できるツールはありますか (1 回限りの使用を考慮して価格設定されています)。おそらく、ここにいる誰かが以前にこのプロセスを経なければならず、共有しても構わない独自のツール/スクリプトを作成したことがありますか?

SSMSは明らかにそれを行いません-クラスター化されていないインデックスの移行スクリプトのみを生成できます（そして、それらはUNIQUE制約ではなくインデックスである必要があります-少なくともいくつかのテーブルでは、良くも悪くも、クラスター化されたインデックスは実際にはありません主キー、それは別のUNIQUE制約です)。

構文が複雑すぎてコード生成を書けないというわけではありません。少なくとも、基本的な主キーの削除と再作成の部分については。しかし、すべての依存関係を把握し、すべての外部キーの削除/再作成スクリプトを生成するオーバーヘッドを追加すると、すべてのテーブルを実行するよりも、自動化して完全にテストする方が多くの作業が必要なしきい値を超えているように感じ始めます。上記の例のように手動で。

問題は、このプロセスを合理的に簡単な方法で自動化できるかどうかです。 私が上に書いたことに代わるものはありますか？

ありがとう！

4

1 に答える 1

2

それを行う最も簡単な方法、IMO は、スキーマ比較ツールの 1 つ (例としてMy tool、red gate の SQL Compare、Apex SQL Diff ) を使用して、スキーマのスクリプトを作成することです。次に、そのスクリプトを編集して、適切なファイル グループに空のすべてのオブジェクトを作成します。それが完了したら、同じツールを使用して新しい DB を正しいファイル グループと比較できます。データを移行するためのスクリプトが生成されます。最も適切なものを見つけるために、複数のものでテストする価値があります。

于 2010-02-02T10:30:37.037 に答える