web-dev-qa-db-ja.com

空き容量の解放

SQL Server 2008 R2でかなり大きなデータベースを実行していますExpress。最近、10 GBの制限に達したため、システムでオブジェクトを作成できなくなりました。

そこにあったデータの約4分の3の非常に大量のレコードをアーカイブしました。

データベースファイルはまだ約10 GBですが、SQL Serverの空き領域を解放するために何かする必要があるかどうか疑問に思っていました。

sql-serverdisk-spacesql-server-2008-r2
3
Alec.

ファイルシステムスペースについて話し、それをオペレーティングシステムに解放する場合は、この操作を手動で行う必要があります。

最初に、各ファイルの空き容量を確認します。

use YourDatabase;
go

;with file_cte as
(
    select
        name,
        physical_name,
        size_mb = 
            convert(decimal(11, 2), size * 8.0 / 1024),
        space_used_mb = 
            convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
    from sys.database_files
)
select
    name,
    physical_name,
    size_mb,
    space_used_mb,
    free_space_mb = size_mb - space_used_mb,
    space_used_percent = 
        convert(decimal(5, 2), space_used_mb / size_mb * 100)
from file_cte;

次に、データベースファイルを圧縮する必要があると確信している場合は、 DBCC SHRINKFILE（） を使用できます。

ファイルを縮小するには、例は次のようになります。

dbcc shrinkfile(YourDataFileName, <target_size_mb>);

しかし、絶対に必要な場合にのみ、データベースファイルを圧縮してください。ファイルが将来同じスペースを再利用する場合、ファイルを縮小しても意味がありません。必要な読み込みは Paul Randalでデータファイルを縮小すべきではない理由 です。

8
Thomas Stringer

そこにあるテーブルを再構築します。これにより、SQL Serverがすべてを再編成して、再利用できるファイル内のスペースの量を最大化します。

DECLARE @sql NVARCHAR(MAX) = N'';

SELECT @sql += N'
ALTER INDEX ALL ON '
  + QUOTENAME(s.name) + N'.' + QUOTENAME(t.name) + N'
  REBUILD WITH 
  (
    FILLFACTOR = 80, 
    STATISTICS_NORECOMPUTE = ON
  );'
FROM sys.schemas AS s
INNER JOIN sys.tables AS t
ON s.[schema_id] = t.[schema_id];

PRINT @sql;
-- EXEC sp_executesql @sql;

other REBUILD options を確認することをお勧めします。または、たとえば、Fill Factorが異なるインデックスがある場合は、動的にして、既存のFILLFACTORで各インデックスを再構築します。 。スクリプトには多くの潜在的な変更がありますが、それは手動で行う必要がないという根拠を形成するはずです。

ファイルを縮小する理由はありません。それは、データを追加し始めるときに再び拡大する必要があることを意味しているだけです。その間に何回ファイルを拡張する必要があるかに関係なく、ファイルが10 GBを超える必要がある場合は、Expressの制限に達します。これらの投稿には、縮小が無駄である理由についての良い情報が含まれています。

データベースを縮小する必要があります-たくさんのスペースを解放しました

トランザクションログが増加し続ける、または領域不足になる理由

6
Aaron Bertrand

SQLデータファイルを大きなストレージボックスのように考えてください。ファイルは特定のサイズに設定されていますが、すべてのスペースが使用されるわけではありません。これは、data/indexes/objects/etcのコンテナーです。現在あるデータについて考えるだけでなく、将来的にデータがどれだけ大きくなるかについて考えたいと思います。データの3/4をアーカイブした場合、時間の経過とともにそのスペースは再び使用されるだけなので、ファイルをそのままにしておくことをお勧めします。

以降、DBファイルの縮小は推奨されません

1）理由によりファイルがそのサイズになり、再びいっぱいになり、自動拡張イベントが発生します。これらの自動拡張イベントは、インスタントファイル初期化が有効になっている場合でも、発生時にI/Oシステムに負担をかける可能性があります。そして

2）ファイルを圧縮すると、圧縮操作によりファイルの最後から（連続した状態で）データが取得され、オープンスペースに以前に再シャッフルされるため、インデックスに深刻な断片化が生じる可能性があります。ファイル内（非隣接状態）。これにより、深刻なパフォーマンスの問題が発生する可能性があります。

4
Kris Gruttemeyer