web-dev-qa-db-ja.com

大きなテーブルを新しいファイルグループに移動した後、プライマリファイルのサイズが変更されなかったのはなぜですか？

近い答えを探して見つけた後、フォローアップを投稿したいと思いますが、これとは別の質問です（ ssdsに合うようにdbを分割 ）

スキャンされたドキュメントを保持する1つのテーブルがあるため、60ギガのデータベースが急速に拡大しています。私たちは古い紙をスキャンしたドキュメントに移動することを推進しており、これがスキャンしたドキュメントの保存を処理する方法であることに選択の余地はありません。新しいファイルグループを追加し、そのテーブルの一意のクラスター化インデックスを新しいFGに再作成して、そのテーブルを新しいFGに移動することを考えていました。

私はテストボックスでそれを行いましたが、驚くべきことに、元のMDFのOSファイルサイズは大幅に変更されませんでした。また、新しいセカンダリFGサイズは、その1つのテーブルのサイズの対応する比率まで変更されませんでした。すべてのテーブル。

OSファイルのサイズは、移動したテーブルのサイズのオーダーで変更する必要があると考えていました。何が足りないのですか？

ありがとう、ビル

Results of testing

sql-serverfilegroups
3
Bill Cummings

SQL Serverのファイルグループからデータを移動したら、DBCC SHRINKFILEコマンドを実行してその物理スペースを再利用する必要があります。

公式ドキュメント には、これについて知っておく必要のあるすべてがありますが、一般的な手法は次のとおりです（この例はドキュメントからのもので、編集されていません）。

USE AdventureWorks2012;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE AdventureWorks2012  
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 1 MB.  
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE AdventureWorks2012  
SET RECOVERY FULL;  
GO

この例では、データベースの名前がAdventureWorks2012であると想定していることに注意してください。ファイルとデータベースの論理名を置き換える必要があります。

上記の例でのリカバリモデルの変更の前後には、適切なバックアップが必要です。バックアップが十分にテストされ、安全なオフサイトの場所にも保存されていることを確認してください。この特定のコマンドによって破損が発生することはありませんが、バックアップは重要です。

1
Randolph West