web-dev-qa-db-ja.com

SQL Server-テーブルの変更と削除および作成

私たちのデータベースはSQL Server 2008 R2です。 datetime2またはbigintに切り替えたいvarchar（500）列のあるテーブルがあります。切り替えられる列のすべてのデータが適切なタイプに対して有効であることを保証できます。列の変更はインデックスには影響しますが、キーには影響しません。

同僚と話し合っている間、私たちは問題に取り組むための2つの方法を見つけました。これらは両方ともT-Sqlスクリプトを介して行われます。

  1. Select intoを使用して一時テーブルを作成し、古いテーブルを削除して、適切なデータ型でテーブルを再作成します。インデックスを再作成します。
  2. ALTER TABLE x ALTER COLUMN Y datetime2を使用して現在のテーブル/データ型を変更し、インデックスを再構築または再作成します。

データがきれいに変換されると確信しているので、私は＃2に傾いています。私の同僚とDBAの友人は＃1を好みますが、私の同僚はなぜ彼らが彼をそのように訓練したのか思い出せません。 DBAの友人は休暇中なので、理由を尋ねませんでした。

誰かがより良いと思うオプションとその理由について洞察を提供できますか？結局のところ、それは私の決定であり、なぜ＃1が＃2よりも優先されるのでしょうか。

sql-serversql-server-2008-r2t-sqlalter-tabledrop-table
6
scottr

私は最近、10億行以上のテーブルを処理したいと思っていた組織でこれを行いました。

アイデアのすべての功績はアーロンバートランド氏にあり、彼のブログ投稿からのものです Trick Shots：Schema Switch-A-Roo

以下のプロセスを小さなテーブルでテストし、PRODで実行する前に快適にしてください。

  1. 2つのスキーマfakeおよびshadowを承認dboで作成します。
  2. shadowスキーマに必要な列とデータ型を含むテーブルを作成します。 _create table shadow.Correct_Table ..._
  3. データを挿入し、元のテーブルがshadowスキーマテーブルに持つすべてのインデックスを作成します。
  4. このように、データとインデックスを持つテーブルの同一のコピーがありますが、それらは異なるスキーマにあります（論理的に分離されています）。
  5. 完了したら、shadowスキーマを使用してテーブルの統計を更新します。

  6. スキーマを切り替える（これはメタデータ操作であり、非常に高速です）

    _--- ALTER SCHEMA TargetSchema TRANSFER SourceSchema.TableName; 

BEGIN TRANSACTION;

  ALTER SCHEMA fake TRANSFER     dbo.original_table;
  ALTER SCHEMA dbo  TRANSFER  shadow.Correct_Table;

COMMIT TRANSACTION;

ALTER SCHEMA shadow TRANSFER fake.Lookup;
_

  7. 最終チェックを行って、すべてが計画どおりに進んだかどうかを確認します。 select count(1) from dbo.Correct_tableを実行する必要があります

  8. 手順7を確認して問題がなければ、_shadow.table_、shadowスキーマおよびfakeスキーマをクリーンアップとして削除します。

9
Kin Shah

これが私の見方です。

＃1の長所

  • 別のテーブルを使用しているため、プロダクションテーブルは、完了するまで使用されます。ロックはありません（データの読み取りに必要なものを超えて）。
  • これは、@ AaronBertrandの発言にも当てはまります。段階的にテストしたり、テストしたりできます。
  • 必要に応じて列の順序を変更できます

＃2の長所

  • 全か無かの操作です。見ていなかったときに、元のテーブルに挿入/変更されたデータを失う可能性はありません。
  • オブジェクトに具体的に割り当てられている権限は保持されます。 ＃1を使用する場合は、スクリプトを作成して適用する必要があります。

言われていることはすべて、私は通常、小さなテーブルまたは停止が発生する可能性がある場合は常に＃2を使用します（ただし、常に事前にバックアップを取ります）。列の順序など。＃1を行う場合は、通常、GUIを使用してスクリプトを生成し、実行する前に注意深く確認します。

4
Kenneth Fisher

ドロップおよび再作成オプションに注意してください。これにより、sys.dependsが奇妙な状態のままになり、列の順序またはタイプが変更されるキャッシュされたプランで問題が発生する可能性があります。

オブジェクトレベルの権限はDROPで失われ、後続のCREATEで自動的に再作成されないため、これらの権限を維持するための手順を実行する必要もあります。

ALTER TABLEはよりクリーンなオプションIMOですが、本番環境でそれを行う前に徹底的にテストして、すべてが正常であることを確認し、操作にかかる時間を確認してください（多くの行があるテーブルでは、これはかなり長くなる可能性があります）時間）。

1
David Spillett

私の同僚は、彼が何を参照しているかについての記事を見つけてしまいました： http://www.nigelrivett.net/SQLAdmin/AlterTableProblems.html 。これを読んで、年末のレポートが近づいていることに気づいた後、列の型に変更を加えないことを決定し、今後数か月でこれを再検討します。記事を読んだ後は、Drop/Createメソッドを使用するだけかもしれません。

これについてフィードバックをくださった皆さんに感謝します。前進することを決定する際に考慮すべき多くの興味深いアプローチ。

1
scottr