私はSQL 2008 r2を実行していますが、非常にアクティブで使用されているテーブルにntextフィールドを追加するまで、データベースは過去3年間正常かつ高速に動作していました。このテーブルのサイズが非常に大きくなっているため、サーバースペースを使い始めています。
何年も高速に動作していたため、dbのインデックス付けを失いたくはありませんし、断片化の支出も受けたくないのです。
そのフィールドとそのすべての値を削除することにしました： ntextフィールドとそのすべての値を削除し、インデックスを削除せず、縮小せずに、dbのパフォーマンスを失うことなくスペースを解放する方法はありますか？
過去5か月のサイズ拡張を示すために、dbサイズクエリ出力を添付します。
回答:
そのフィールドとそのすべての値を削除することにしました：ntextフィールドとそのすべての値を削除し、インデックスを削除せず、縮小せずに、dbのパフォーマンスを失うことなくスペースを解放する方法はありますか？
使用することをお勧めします（BOLから:)
DBCC CLEANTABLE
(
{ database_name | database_id | 0 }
, { table_name | table_id | view_name | view_id }
[ , batch_size ]
)
[ WITH NO_INFOMSGS ]DBCC CLEANTABLEは、可変長列が削除された後にスペースを再利用します。可変長列は、varchar、nvarchar、varchar（max）、nvarchar（max）、varbinary、varbinary（max）、text、ntext、image、sql_variant、およびxmlのいずれかのデータ型にすることができます。このコマンドは、固定長列が削除された後、スペースを再利用しません。
!! 注意 !! （注意深いバッチサイズを使用します-テーブルが大きい場合は、このパラメーターを使用することをお勧めします）：
DBCC CLEANTABLEは、1つ以上のトランザクションとして実行されます。バッチサイズが指定されていない場合、コマンドは1つのトランザクションでテーブル全体を処理し、操作中はテーブルが排他的にロックされます。一部の大きなテーブルでは、単一のトランザクションの長さと必要なログスペースが大きすぎる場合があります。バッチサイズが指定されている場合、コマンドは一連のトランザクションで実行され、各トランザクションには指定された行数が含まれます。DBCC CLEANTABLEは、別のトランザクション内のトランザクションとして実行できません。
この操作は完全に記録されます。
単純な再現はDBCC CLEANTABLE、縮小よりも優れていることを証明します（断片化の心配はありません:-)
-- clean up
drop table dbo.Test
-- create test table with ntext column that we will drop later
create table dbo.Test (
col1 int
,col2 char(25)
,col3 ntext
);
-- insert 1000 rows of test data
declare @cnt int;
set @cnt = 0;
while @cnt < 1000
begin
select @cnt = @cnt + 1;
insert dbo.Test (
col1
,col2
,col3
)
values (
@cnt
,'This is a test row # ' + CAST(@cnt as varchar(10)) + 'A'
,REPLICATE('KIN', ROUND(RAND() * @cnt, 0))
);
end
--drop the ntext column
ALTER TABLE dbo.Test DROP COLUMN col3 ;
--reclaim the space from the table
-- Note that my table is only having 1000 records, so I have not used a batch size
-- YMMV .. so find a maintenance window and you an appropriate batch size
-- TEST TEST and TEST before implementing in PROD.. so you know the outcome !!
DBCC CLEANTABLE('tempdb', 'dbo.Test') ;
ほとんどの部分について、私はPaul RandallのInside the storage engineブログシリーズを参照しています。
SQLServerのデータベースファイルから未使用領域を再生する唯一の方法は、DBCC SHRINKコマンドを使用してデータベースファイル内のデータを再割り当てし、ページを解放し、グローバルアロケーションマップから削除した後、データベースファイルから削除します。この操作は遅く、データベース内で断片化を作成し、LOBページはデータベースファイル内のリンクリストとして保存されるため、LOBページを処理する場合はさらに遅くなります。
NTEXT列をドロップしているため、縮小する前にゴーストクリーンアッププロセスがデータをドロップするのを待つ必要があります。
現在、データベースファイルに多くの空き領域があれば、実際には問題はありません。ディスク領域がある場合、バックアップ圧縮がファイル内の空き領域を処理します。
絶対にファイルを小さくしたい場合は、データベースで新しいファイルグループを作成し、それをデフォルトにしてからテーブルを新しいファイルグループに移動できますが、これには時間がかかり、ダウンタイムが発生する可能性があります。ボブ・プサテリがここで説明したテクニックを使用して、良い結果を得ました。
他のデータベース/非DBファイル用にそのスペースが必要なため、またはこのデータベースのスペース不足で問題があるため、データベースファイルを縮小しますか？
2番目の場合は、考えているほど大きな問題はないかもしれません。私が正しければ、データベースが新しいデータ用の追加スペースを得るために成長する必要があるときです。列を削除すると、その列が占めていたすべてのスペースが解放され、データベース内のテーブルに新しい行が追加されます。これは、データベースの成長が必要になるまでに時間がかかることを意味します。それまでの間、データドライブ用に追加のスペースを確保します。ほとんどのデータベースは時間とともに成長しますが、ドライブの空き領域に十分な余裕があると便利です。
問題のある列のないミラーテーブルを作成し、このテーブルにすべてのデータをコピーし、元のテーブルを削除して、ミラーテーブルの名前を変更します。