1 億 5000 万以上のレコードを持つテーブルがあります。すべての行をクリア/削除する必要があります。t-logs への書き込みが原因で、削除操作に時間がかかり、DB 全体の復旧モデルを変更することはできません。テーブルの切り捨てオプションをテストしました。
truncate はテーブルからページの割り当てを解除し、私が間違っていなければそれらを再利用できるようにしますが、データベースを自動的に縮小しません。したがって、DB サイズを縮小したい場合は、テーブルを切り捨てた後に、shrink db コマンドを実行する必要があります。
これは通常の手順ですか？注意する必要があること、または注意する必要があること、またはより良い代替手段はありますか?
「すべての行を削除する」... DROP TABLE (および同じスキーマ/インデックスで空のテーブルを再作成する) が望ましいでしょうか? （私は個人的に「新たなスタート」が好きです;-)）
これは、TRUNCATE TABLE もまったく問題ないと言いました。はい、スペースを回復したい場合は、後で DBCC SHRINKFILE が必要になる場合があります。
truncateあなたが探しているものです。後でデータベースをスリム化する必要がある場合は、縮小を実行します。
このMSDNリファレンス (T-SQL について話している場合) では、行の削除と切り捨ての舞台裏を比較しています。
指摘したように、切り捨てまたはドロップを使用できない場合
SELECT 1
WHILE @@ROWCOUNT <> 0
DELETE TOP (100000) MyTable
データベース全体のサイズによっては、縮小に時間がかかる場合があります。一度にすべてを元に戻そうとするよりも、小さなチャンクに縮小した方が速くなることがわかりました。
テーブルからすべてのレコードを削除する通常の解決策（切り捨て+データベースの縮小）があります。
アーウィンが指摘したように。TRUNCATE コマンドは、外部キー制約によって参照されている間は機能しません。したがって、最初に制約を削除し、テーブルを切り捨てて、制約を再作成します。
パフォーマンス に関心があり、これがシステムの通常のルーチンである場合。このテーブルを独自のデータ ファイルに移動することを検討してから、ターゲット データファイルに対してのみ圧縮を実行してください。
Truncate Table (および drop table) で覚えておくべきことの 1 つは、テーブルを参照する外部キーがある場合、これは機能しないということです。