web-dev-qa-db-ja.com

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

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

sql-serversql-server-2012truncate
23
Lucas Rodrigues Sena

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

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

ベストプラクティス

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

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

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

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

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

また注意してください：

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

これを行う際に考慮すべきことは確かにいくつかあります。この操作を行うと何が起こるかについて Paul Randalのブログ投稿 を参照することをお勧めします。

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

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;
25
Thomas Stringer

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

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

データベースをオフラインにできない場合は、DBCC SHRINKFILEコマンドと[〜＃〜 ] emptyfile [〜＃〜]オプション。

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

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

6
stacylaray

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

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

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

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

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

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

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

あなたは待つ必要があり、もちろん手動で ファイルを縮小 スペースを再利用する必要があります。これは、縮小が論理的な断片化を引き起こすので、必要が重大でない限り回避する必要があることにも言及する価値があります。縮小と断片化のバランスを取る必要があります。データが再び増大するシナリオを考慮して、縮小によって実際に問題が解決するかどうかを自問することをお勧めします。

以下のクエリを使用して、データベースにどれだけの空き容量があるかを確認します

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