データベースの圧縮
データベース内の各ファイルを縮小して未使用のページを削除できます。データベース エンジンにより領域は効率的に再利用されますが、サイズの大きなファイルをそのまま保持する必要がない場合もあります。このような場合には、ファイルの圧縮が必要になることがあります。データ ファイルとトランザクション ログ ファイルはどちらも縮小したり、圧縮したりすることができます。データベース ファイルはグループ単位または個別に手動で圧縮できます。また、データベース自体を、指定した間隔で自動的に圧縮するように設定することもできます。
ファイルは常に末尾から圧縮されます。たとえば、5 GB のファイルがある場合に、DBCC SHRINKFILE ステートメントの target_size に 4 GB を指定すると、データベース エンジンにより、ファイルの末尾の 1 GB から可能な限り多くの領域が解放されます。解放するファイルの領域に使用済みのページがあると、データベース エンジンにより、それらのページは解放されていない領域に最初に再配置されます。データベースは、空き領域が残っていない時点までしか圧縮できません。たとえば、5 GB のデータベースに 4 GB のデータが格納されていて、DBCC SHRINKFILE ステートメントの target_size に 3 GB を指定した場合、解放されるのは 1 GB だけです。
データベースの自動圧縮
AUTO_SHRINK データベース オプションが ON に設定されていると、データベース エンジンにより、空き領域のあるデータベースが自動的に圧縮されます。このオプションは、ALTER DATABASE ステートメントを使用して設定します。既定では、このオプションは OFF に設定されます。データベース エンジンは、各データベース内の領域の使用状況を定期的に調査します。データベースで AUTO_SHRINK オプションが ON に設定されていると、データベース エンジンにより、データベース内のファイルのサイズが縮小されます。この処理はバックグラウンドで行われ、データベース内でのユーザーの操作に影響することはありません。
データベースが自動的に圧縮されるように設定するには
データベースの手動圧縮
DBCC SHRINKDATABASE ステートメントまたは DBCC SHRINKFILE ステートメントを使用して、データベースやデータベース内のファイルを手動で圧縮できます。DBCC SHRINKDATABASE ステートメントまたは DBCC SHRINKFILE ステートメントが、ログ ファイル内の指定された領域をすべて確保できない場合、解放できる領域を増やすためにユーザーが実行すべき操作を示す情報メッセージを表示します。ログ ファイルの圧縮の詳細については、「トランザクション ログの圧縮」を参照してください。
DBCC SHRINKDATABASE 操作と DBCC SHRINKFILE 操作は処理中の任意の時点で停止することができ、停止時に完了していた作業はすべて保持されます。
DBCC SHRINKDATABASE ステートメントを使用する場合、データベース全体を作成時よりも小さいサイズに圧縮することはできません。したがって、作成時のサイズが 10 MB のデータベースが 100 MB まで拡張した場合、データベース内のすべてのデータを削除したとしても、縮小できる限界は 10 MB までです。
ただし、DBCC SHRINKFILE ステートメントを使用すると、個別のデータベース ファイルを初期サイズよりも小さいサイズに圧縮できます。データベース全体を圧縮するのではなく、各ファイルを個別に圧縮する必要があります。
.gif "注意") 注 |
|---|
データベースまたはトランザクション ログは、バックアップ中に圧縮できません。また、圧縮中にバックアップを作成することもできません。 |
データベースを圧縮するには
データ ファイルまたはログ ファイルを圧縮するには
トランザクション ログの圧縮
トランザクション ログ ファイルは圧縮できる限界が決まっています。圧縮できるサイズは、ログ ファイル内の仮想ログ ファイルのサイズによって決まります。そのため、仮想ログ ファイルよりも小さいサイズにログ ファイルを圧縮することはできません。また、ログ ファイルの縮小単位は、仮想ログ ファイルと同じサイズです。たとえば、1 GB のトランザクション ログ ファイルは、それぞれが 200 MB の 5 つの仮想ログ ファイルで構成されることがあります。トランザクション ログ ファイルを圧縮すると、未使用の仮想ログ ファイルが削除されますが、少なくとも 2 つの仮想ログ ファイルが残ります。この例では各仮想ログ ファイルのサイズが 200 MB なので、トランザクション ログ ファイルは 400 MB までしか縮小できず、また、200 MB 単位でしか縮小できません。トランザクション ログ ファイルを小さいサイズまで縮小できるようにするには、一度に大きなトランザクション ログ ファイルを作成するのではなく、小さなトランザクション ログ ファイルを作成し、そのファイルが自動的に拡張されるように設定します。
DBCC SHRINKDATABASE 操作または DBCC SHRINKFILE 操作により、トランザクション ログ ファイルが要求されたサイズまですぐに圧縮されます (丸め処理が行われることを前提とします)。ログ ファイルは圧縮する前にバックアップする必要があります。バックアップすると、論理ログのサイズが縮小され、論理ログのどの部分も保持しない仮想ログに非アクティブのマークが設定されます。詳細については、「トランザクション ログの圧縮」を参照してください。
ベスト プラクティス
データベースまたはファイルを圧縮する場合は次のことを考慮してください。
圧縮操作は、テーブルの切り捨てやテーブルの削除操作など、大きな未使用領域を生成する操作の後に実行すると最も効果的です。
ほとんどのデータベースでは、毎日の定期的操作で使用するための空き領域がある程度必要です。データベースを何度圧縮しても、データベースのサイズが大きくなってしまう場合は、通常の操作にそれだけの領域が必要であることを示しています。このような場合、繰り返しデータベースを圧縮することは無意味です。
圧縮操作では、データベース内のインデックスの断片化状態は保持されず、一般に、断片化の程度が大きくなります。たとえば、インデックスを再構築した後は、データベース ファイルまたはデータ ファイルを圧縮しないことをお勧めします。この理由からも、データベースを繰り返し圧縮することはお勧めできません。
特に必要のない限り、AUTO_SHRINK データベース オプションを ON に設定しないでください。
行のバージョン管理に基づく分離レベルと圧縮操作
行のバージョン管理に基づく分離レベルで実行されているトランザクションによって圧縮操作がブロックされる可能性があります。たとえば、DBCC SHRINK DATABASE 操作の実行中に、行のバージョン管理に基づく分離レベルで大規模な削除操作が実行されている場合、圧縮操作によるファイルの圧縮は、削除操作が完了するまで待機します。この場合、DBCC SHRINKFILE 操作および DBCC SHRINKDATABASE 操作では、最初の 1 時間は 5 分ごとに、それ以降は 1 時間ごとに、SQL Server エラー ログに情報メッセージ (SHRINKDATABASE の場合は 5202、SHRNKFILE の場合は 5203) が出力されます。詳細については、「DBCC SHRINKDATABASE (Transact-SQL)」を参照してください。