200GBのテーブルは切り捨てられましたが、ディスク領域は解放されていません

23

残り2GBしかないため、この履歴テーブルを削除する必要があります。このテーブルは空になりましたが、データベースのディスク容量は解放されていません。また、データベースファイルは320GBです。

sql-server sql-server-2012 truncate

データベース上にレプリケーションの痕跡をいくつか見つけました。これにより、ログサイズが劇的に増加し、削除や縮小ができなくなりました。

— ルーカスロドリゲスセナ

25

ボリューム上の実際のデータベースファイル消費を参照している場合、SQL Serverはそれを自動的に処理しません。データベースからデータを削除したからといって、データベースファイルが既存のデータのみに収まるように縮小されるわけではありません。

ボリューム上のスペースを再利用する必要がある場合、探しているのは、で特定のファイルを縮小することですDBCC SHRINKFILE。そのドキュメントによると、いくつかのベストプラクティスに注目する価値があります。

ベストプラクティス

ファイルを圧縮する場合は、次の情報を考慮してください。

縮小操作は、テーブルの切り捨て操作やテーブルの削除操作など、多くの未使用領域を作成する操作の後に最も効果的です。

ほとんどのデータベースでは、通常の日常業務に使用できる空き領域が必要です。データベースを繰り返し縮小し、データベースサイズが再び大きくなっていることに気付いた場合、これは通常の操作に縮小されたスペースが必要であることを示しています。これらの場合、データベースを繰り返し縮小することは無駄な操作です。

縮小操作では、データベース内のインデックスの断片化状態が保持されず、一般的にある程度断片化が増加します。これは、データベースを繰り返し圧縮しないもう1つの理由です。

同じデータベース内の複数のファイルを同時にではなく順次に圧縮します。システムテーブルでの競合は、ブロッキングによる遅延を引き起こす可能性があります。

また注意事項：

DBCC SHRINKFILE 操作はプロセスの任意の時点で停止でき、完了した作業は保持されます。

これを行う際に考慮すべきことがいくつかあります。PaulRandalのブログ投稿をご覧になることをお勧めしますかあります。この操作を行うとどうなるかについてを。

最初のステップは、実際に置き換えることができるスペースと空きスペース、およびファイルの使用済みスペースを確認することです。

use AdventureWorks2012;
go

;with db_file_cte as
(
    select
        name,
        type_desc,
        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,
    type_desc,
    physical_name,
    size_mb,
    space_used_mb,
    space_used_percent = 
        case size_mb
            when 0 then 0
            else convert(decimal(5, 2), space_used_mb / size_mb * 100)
        end
from db_file_cte;

— トーマス・ストリンガー
ソース

6

これは、テーブルを切り捨てるときの通常の動作であり、Per Books Onlineとして128を超えるエクステントの削除を伴います

大きなインデックスを削除または再構築するか、大きなテーブルを削除または切り捨てると、データベースエンジンは、トランザクションがコミットされるまで、実際のページの割り当て解除とそれに関連するロックを延期します。この実装は、マルチユーザー環境で自動コミットと明示的なトランザクションの両方をサポートし、128を超えるエクステントを使用する大きなテーブルとインデックスに適用されます。

データベースエンジンは、プロセスを論理と物理の2つの別々のフェーズに分割することにより、大きなオブジェクトを削除するために必要な割り当てロックを回避します。

論理フェーズでは、テーブルまたはインデックスで使用されている既存の割り当てユニットに割り当て解除のマークが付けられ、トランザクションがコミットされるまでロックされます。クラスター化インデックスが削除されると、データ行がコピーされ、ストアに作成された新しい割り当て単位に、再構築されたクラスター化インデックスまたはヒープのいずれかに移動されます。（インデックスの再構築の場合、データ行もソートされます。）ロールバックがある場合、この論理フェーズのみをロールバックする必要があります。

物理フェーズは、トランザクションがコミットされた後に発生します。割り当て解除のマークが付けられた割り当てユニットは、物理的にバッチで削除されます。これらのドロップは、バックグラウンドで発生する短いトランザクション内で処理され、多くのロックを必要としません。

物理フェーズはトランザクションのコミット後に発生するため、テーブルまたはインデックスのストレージスペースはまだ利用できないように見える場合があります。物理フェーズが完了する前にデータベースを拡張するためにこのスペースが必要な場合、データベースエンジンは、割り当て解除のためにマークされた割り当てユニットからスペースを回復しようとします。これらの割り当てユニットで現在使用されているスペースを見つけるには、sys.allocation_unitsカタログビューを使用します。

遅延ドロップ操作は、割り当てられたスペースをすぐには解放せず、データベースエンジンに追加のオーバーヘッドコストをもたらします。したがって、128以下のエクステントを使用するテーブルとインデックスは、SQL Server 2000と同様に削除、切り捨て、再構築されます。これは、トランザクションがコミットされる前に論理フェーズと物理フェーズの両方が発生することを意味します。

待つ必要があり、もちろん手動でファイルを縮小する必要がありますしてスペースを再利用する必要があります。縮小は論理的な断片化を引き起こすので、必要がない限り避けてください。縮小と断片化のバランスをとる必要があります。データが再び成長するシナリオを考慮して、縮小が実際に問題を解決するかどうかを自問する方が良いでしょう。

以下のクエリを使用して、データベースにどのくらいの空き領域があるかを確認します

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

— シャンキー
ソース

6

トムとシャンキーの回答に加えて、データベースにLOB / BLOBデータが含まれている場合、DBCC SHRINKFILEは機能しない可能性があります。その場合、データベースをオフラインにできるかどうかに応じて、2つのオプションがあります。データベースをオフラインにできる場合は、データをコピーしてからコピーして、空のスペースを削除する必要があります。これは、次のいずれかで実現できます。

SELECT INTOステートメントを使用して、テーブル全体を新しいテーブルに転送します。元のテーブルを削除し、DBCC SHRINKFILEを実行します。新しいテーブルの名前を元のテーブル名に変更します。
bcpを使用してテーブルをネイティブモードでコピーし、テーブルを削除し、DBCC SHRINKFILEを実行し、テーブルを作成してから、データをテーブルにbcpします。
エクスポート/インポートを使用して、すべてのデータを新しいデータベースに移動し、既存のデータベースを削除し、新しいデータベースの名前を元のデータベース名に変更します。

データベースをオフラインにできない場合、EMPTYFILEオプションを指定してDBCC SHRINKFILEコマンドを使用できます。

オフラインコピーの詳細：http : //support.microsoft.com/kb/324432/en-us

EMPTYFILEオプションの現在の情報 http://msdn.microsoft.com/en-us/library/ms189493(v=sql.105).aspx

— スタシラライ
ソース