私は SQL Server 2008 を使用しており、約 5,000 万行を含むテーブルがあります。
そのテーブルには、タイプ のプライマリ ID 列が含まれていますint
。
その列を にアップグレードしたいと思いますbigint
。
DB サーバーを使用できなくせず、データを削除または破壊しない迅速な方法でそれを行う方法を知る必要があります。
どうすればいいですか?それを行うことの結果は何ですか?
私は SQL Server 2008 を使用しており、約 5,000 万行を含むテーブルがあります。
そのテーブルには、タイプ のプライマリ ID 列が含まれていますint
。
その列を にアップグレードしたいと思いますbigint
。
DB サーバーを使用できなくせず、データを削除または破壊しない迅速な方法でそれを行う方法を知る必要があります。
どうすればいいですか?それを行うことの結果は何ですか?
まあ、これを行うのは簡単ではありません....
私のアプローチは次のとおりです。
ID
同一の構造を持つ新しいテーブルを作成します-列がBIGINT IDENTITY
代わりにあることを除いてINT IDENTITY
----[ここでサーバーを排他的なシングルユーザーモードにします。ユーザーはこの時点からあなたのサーバーを使用できません]----
テーブルを参照しているすべての外部キー制約を見つけて無効にします
順番SET IDENTITY_INSERT (your new table) ON
古いテーブルの行を新しいテーブルに挿入します
順番SET IDENTITY_INSERT (your new table) OFF
古いテーブルを削除する
新しいテーブルの名前を古いテーブル名に変更します
BIGINT
代わりに使用するテーブルへのFK参照を持つすべてのテーブルを更新しますINT
(単純な で実行できるはずですALTER TABLE ..... ALTER COLUMN FKID BIGINT
)
すべての外部キー関係を再作成します
これで、サーバーを通常のマルチユーザー使用に戻すことができます
私は何が欠けていますか?
なぜこれができないのですか:
ALTER TABLE tableName ALTER COLUMN ID bigint
最初にテスト環境で試してみると思いますが、これは常にうまくいきます
おそらく最善の方法は、BIGINT IDENTITY 列を持つ新しいテーブルを作成し、SET IDENTITY_INSERT ON を使用して既存のデータを移動することです。次に、テーブルの名前を変更します。これは、Management Studio でデータ型を変更した場合と同様に、メンテナンス ウィンドウ中に行う必要があります (同様に、新しいテーブルを作成し、データを移動し、プロセス内の全員をブロックします)。
Int の代わりに BigInt を IDENTITY として使用したいのはなぜですか?
次のシナリオを考えてみましょう: データベースは、ライブ本番環境の 1 つのインスタンスと、(TestA、B、C など)、(QA A、B、C など)、(Demo A、 B、Cなど)、(UAT A、B、Cなど)、(トレーニングA、B、Cなど) 何度も何度も... あなたは知りたくありません...
このデータベース IDENTITY フィールドは、非運用環境の共有環境であるサード パーティ プロバイダーに一意の番号を渡すために使用されます。ベンダーは、複数の環境をセットアップするために腕と脚を請求するため、会社は本番 DB 用に 1 つ、他のすべての DB 用に 1 つを使用します。
したがって...非実稼働環境でテストが行われる場合、これらの数値は、たまたまテストしている非実稼働環境から互いに交差することはありません。また、テストにはストレステストが含まれます...一度に数十万行を送信します。
さらに、これらの環境はすべて本番環境で更新されるため、ID フィールドは本番環境にあったものでリセットされます。そのため、各環境でどのスプレッドが使用されたかを追跡し、IDENTITY を以前に使用されたことのない新しいスプレッドにリセットする必要があります。これらの環境ですでに番号が再度送信されると、サード パーティ ベンダーは吐き気を催します。また、ベンダーは、これらの番号を最後に更新またはリセットすることを望まないか、または行うことができません。
これは現実の問題であり、現在のフィールドはすべての環境で int のままであり、これらのスプレッドを追跡する管理は、四半期ごとに、または誰かが何百ものトランザクションに対して大規模なストレス テストを行うたびに更新されます。
したがって、約 10 年以内に、この IDENTITY を BIGINT に更新するか、誰かがサードパーティ ベンダーに更新するよう説得する必要があります。
そうそう、経営陣は、すべてが突然崩壊するまで、それについてネズミのお尻を与えることができます.
次に、HACK "ALTER TABLE tableName ALTER COLUMN ID bigint" で問題なく実行できます。スペースとインデックスの処理が安い!