DBCC SHRINKDATABASE (Transact-SQL)

DBCC SHRINKDATABASE では、データ ファイルはファイルごとに圧縮されますが、ログ ファイルはすべてが 1 つの連続的なログ プールに存在するものとして圧縮されます。ファイルは常に末尾から圧縮されます。

たとえば、mydb という名前のデータベースに、1 つのデータ ファイルと 2 つのログ ファイルがあり、各データ ファイルとログ ファイルのサイズは 10 MB で、データ ファイルには 6 MB のデータが格納されているとします。

この場合、それぞれのファイルについて、データベース エンジンでは目標サイズが計算されます。これはファイルの圧縮後のサイズです。DBCC SHRINKDATABASE を target_percent と共に指定すると、データベース エンジンでは、圧縮後にファイル内の空き領域が target_percent になるように目標サイズが計算されます。たとえば、mydb を圧縮する場合に target_percent を 25 と指定すると、データベース エンジンではデータ ファイルの目標サイズが 8 MB (6 MB のデータに 2 MB の空き領域を加えたもの) と計算されます。したがって、データベース エンジンではデータ ファイルの末尾 2 MB にあるすべてのデータがデータ ファイルの先頭 8 MB にある空き領域に移動されてから、ファイルが圧縮されます。

次に、mydb のデータ ファイルに 7 MB のデータが格納されているとします。target_percent を 30 にした場合、このデータ ファイルは空き領域のパーセンテージが 30 になるように圧縮されますが、target_percent を 40 にした場合、データ ファイルは圧縮されません。データベース エンジンでは、圧縮後のファイル サイズが現在のデータ占有領域よりも小さくなる場合、ファイルは圧縮されません。別の考え方をすれば、目的の空き領域 40% にデータ ファイル最大容量の 70% (10 MB 中の 7 MB) を加算すると、100% を超えます。30 を超える値を target_size に指定すると、目的の空き領域のパーセンテージと、データ ファイルの現在の占有パーセンテージを加算した値が 100% を超えるので (この場合は 10% 超過)、データ ファイルは圧縮されません。

ログ ファイルの場合、データベース エンジンでは target_percent を使用してログ全体の目標サイズが計算されます。つまり、target_percent は圧縮操作後のログ内の空き領域サイズになります。計算の後、ログ全体の目標サイズは各ログ ファイルの目標サイズに変換されます。

DBCC SHRINKDATABASE では、各物理ログ ファイルの目標サイズへの圧縮がすぐに試行されます。ログ ファイルの目標サイズを超える仮想ログ内に論理ログの部分がない場合は、ログ ファイルは目標サイズまで正常に切り捨てられ、DBCC SHRINKDATABASE はメッセージなしで終了します。しかし、目標サイズを超える仮想ログ内に論理ログの一部がある場合は、データベース エンジンによってできるだけ多くの領域が解放され、情報メッセージが出力されます。このメッセージには、ファイルの末尾で仮想ログから論理ログを移動するために行う必要のある操作が説明されています。この操作を実行した後、DBCC SHRINKDATABASE を使って、残りの領域を解放できます。詳細については、「トランザクション ログの圧縮」を参照してください。

ログ ファイルは仮想ログ ファイルの境界を越えて圧縮できないため、ログ ファイルを仮想ログ ファイルのサイズより小さく圧縮することはできません。これはログ ファイルが使用されていない場合でも同じです。仮想ログ ファイルのサイズは、ログ ファイルの作成時または拡張時に、データベース エンジンにより動的に選択されます。仮想ログ ファイルの詳細については、「トランザクション ログの物理アーキテクチャ」を参照してください。

データベースを圧縮する場合は次のことを考慮してください。

• 圧縮操作は、テーブルの切り捨てやテーブルの削除操作など、大きな未使用領域を生成する操作の後に実行すると最も効果的です。

• ほとんどのデータベースでは、毎日の定期的操作で使用するための空き領域が必要です。データベースを何度圧縮しても、データベースのサイズが大きくなってしまう場合は、通常の操作にそれだけの領域が必要であることを示しています。このような場合、繰り返しデータベースを圧縮することは無意味です。

• 圧縮操作では、データベース内のインデックスの断片化状態は保持されず、一般に、断片化の程度が大きくなります。この理由からも、データベースを繰り返し圧縮することはお勧めできません。

• 特別な要件がない限り、AUTO_SHRINK データベース オプションを ON に設定しないでください。

トランザクションが行のバージョン管理に基づく分離レベルで実行されている場合、圧縮操作がブロックされることがあります。たとえば、DBCC SHRINK DATABASE 操作を実行するときに、行のバージョン管理に基づく分離レベルでの大規模な削除操作が進行中の場合、圧縮操作は削除処理が完了してから実行され、ファイルが圧縮されます。この場合、DBCC SHRINKFILE および DBCC SHRINKDATABASE 操作では、最初の 1 時間は 5 分ごとに、それ以降は 1 時間ごとに、SQL Server エラー ログに情報メッセージ (SHRINKDATABASE の場合は 5202、SHRINKFILE の場合は 5203) が出力されます。たとえば、エラー ログに次のエラー メッセージが含まれているとします。

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot 
transaction with timestamp 15 and other snapshot transactions linked to 
timestamp 15 or with timestamps older than 109 to finish.

これは、スナップショット トランザクションに、圧縮操作により完了された最後のトランザクションである 109 より古いタイムスタンプがあり、それによって圧縮操作がブロックされていることを意味しています。また、sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) 動的管理ビューの transaction_sequence_num 列または first_snapshot_sequence_num 列に、値 15 が含まれることも示しています。このビューの transaction_sequence_num 列または first_snapshot_sequence_num 列のいずれかに、圧縮操作により完了した最後のトランザクション (109) より低い番号が含まれている場合は、それらのトランザクションが終了するまで圧縮操作は待機状態となります。

この問題を解決するには、次のいずれかの作業を実行します。

• 圧縮操作をブロックしているトランザクションを終了します。

• 圧縮操作を終了します。完了済みの作業は保持されます。

• 何もせず、ブロックしているトランザクションが完了するまで圧縮操作を待機状態にしておきます。

SQL Server のエラー ログの詳細については、「SQL Server エラー ログの表示」を参照してください。

次の例では、UserDB ユーザー データベース内のデータ ファイルとログ ファイルのサイズを圧縮して、データベースの空き領域が 10% になるようにします。

DBCC SHRINKDATABASE (UserDB, 10);
GO

次の例では、AdventureWorks サンプル データベースのデータ ファイルを、最後に割り当てられたエクステントまで圧縮します。

DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);