DBCC SHRINKDATABASE (Transact-)SQL)

• p
• M
• j
• i
• K
• +12

適用対象製品です。 SQL Server（サポートされるすべてのバージョン）Azure SQL Database Azure Synapse Analytics

指定したデータベースのデータおよびログ ファイルのサイズを縮小します。

Transact-SQL Syntax Conventions

構文

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 

-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

引数

database_name | database_id | 0
シュリンクするデータベース名またはIDです。 0は現在のデータベースを使用することを指定します。

target_percent
は、データベースの縮小後にデータベース・ファイルに残しておきたい空き領域の割合です。

NOTRUNCATE
ファイルの末尾から割り当てページをファイルの先頭にある未割り当てページに移動させます。 target_percentは省略可能です。 Azure Synapse Analyticsはこのオプションをサポートしていません。

ファイル末尾の空き領域はオペレーティング システムに返されず、ファイルの物理サイズは変更されません。 そのため、NOTRUNCATE を指定してもデータベースは縮小しないように見えます。

NOTRUNCATEはデータ・ファイルにのみ適用されます。 NOTRUNCATEはログ・ファイルに影響しません。

TRUNCATEONLY
ファイルの末尾にあるすべての空き領域をオペレーティング・システムに解放します。 ファイル内のページは移動しません。 データファイルは最後に割り当てられたエクステントにのみ縮小されます。 TRUNCATEONLYで指定された場合、target_percentは無視されます。 Azure Synapse Analyticsはこのオプションをサポートしていません。

TRUNCATEONLY はログ ファイルに影響します。 データファイルのみを切り捨てるには、DBCC SHRINKFILEを使用します。

WITH NO_INFOMSGS
重大度レベルが0から10までのすべての情報メッセージを抑制します。

結果セット

次の表は、結果セットの列を説明するものです。

備考

特定のデータベースのすべてのデータおよびログファイルを縮小するには、DBCC SHRINKDATABASEコマンドを実行します。 特定のデータベースのデータまたはログファイルを一度に縮小するには、DBCC SHRINKFILEコマンドを実行します。

データベース内の現在の空き（未割り当て）領域の量を表示するには、sp_spaceusedを実行します。

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

設定した最小サイズのデータベースより小さいサイズは設定できません。 最小サイズは、データベースを最初に作成するときに指定します。 または、ファイルサイズ変更操作を使用して明示的に設定された最後のサイズを最小サイズとすることができます。 DBCC SHRINKFILE や ALTER DATABASE などの操作は、ファイル サイズ変更操作の例です。

あるデータベースが、最初に 10 MB のサイズで作成されたとします。 その後、それは100MBに成長する。 DBCC SHRINKDATABASEを実行するときに、NOTRUNCATEオプションまたはTRUNCATEONLYオプションのいずれかを指定してください。 指定しない場合、NOTRUNCATEを指定してDBCC SHRINKDATABASE操作を実行した後、TRUNCATEONLYを指定してDBCC SHRINKDATABASE操作を実行した場合と同じ結果になります。 縮小されたデータベースはシングルユーザーモードである必要はありません。縮小されたデータベースでは、システムデータベースを含む他のユーザーが作業できます。 逆に、データベースの縮小操作の処理中にデータベースをバックアップすることはできません。

How DBCC SHRINKDATABASE Works

DBCC SHRINKDATABASE はファイルごとにデータファイルを縮小しますが、ログファイルはすべてのログファイルが 1 つの連続したログプールに存在するかのように縮小します。

いくつかのログ ファイル、データ ファイル、および mydb という名前のデータベースを持っていると仮定します。 データファイルとログファイルはそれぞれ10 MBで、データファイルには6 MBのデータが含まれています。 Database Engine は各ファイルのターゲットサイズを計算します。 この値は、ファイルが縮小されるサイズです。 DBCC SHRINKDATABASE に target_percent を指定すると、Database Engine はターゲット サイズを縮小後のファイルの target_percent の空き容量として計算します。 そのため、Database Engine はデータ ファイルの最後の 2 MB からデータ ファイルの最初の 8 MB の空き領域にデータを移動し、ファイルを縮小します。

mydb のデータ ファイルに 7 MB のデータが含まれていると仮定します。 target_percentに30を指定すると、このデータファイルは空き率30に縮小されます。 しかし、target_percent を 40 に指定しても、Database Engine は現在データが占めているサイズより小さいサイズにファイルを縮小しないため、データ ファイルは縮小しません。

この問題を別の方法で考えることもできます。 40% の空き領域 + 70% のフル データ ファイル (10 MB 中の 7 MB) は 100% 以上です。 30 より大きい target_size は、データ ファイルを縮小しません。 これは、必要な空き領域の割合とデータ ファイルが占める現在の割合が 100 パーセントを超えているからです。

ログ ファイルの場合、Database Engine はログ全体のターゲット サイズを計算するために target_percent を使用します。 そのため、target_percent は縮小操作後のログ内の空き領域の量です。 ログ全体のターゲット サイズは、次に各ログ ファイルのターゲット サイズに変換されます。

DBCC SHRINKDATABASE は、各物理ログ ファイルをすぐにそのターゲット サイズに縮小しようとします。 論理ログのどの部分も、ログファイルの目標サイズを越えて仮想ログに残らないとします。 すると、ファイルは正常に切り捨てられ、DBCC SHRINKDATABASEは何のメッセージも出さずに終了します。 しかし、論理ログの一部が目標サイズを越えて仮想ログに残っている場合、データベースエンジンは可能な限りスペースを解放し、情報メッセージを発行します。 このメッセージには、ファイルの最後に論理ログを仮想ログから移動させるために必要なアクションが記述されています。 アクションが実行された後、DBCC SHRINKDATABASE を使用して残りのスペースを解放できます。

ログ ファイルは、仮想ログ ファイル境界までしか縮小できません。 そのため、仮想ログファイルのサイズより小さいサイズにログファイルを縮小することはできない場合があります。 使用されていない場合でも不可能な場合があります。 仮想ログ ファイルのサイズは、ログ ファイルの作成または拡張時に Database Engine によって動的に選択されます。

ベスト プラクティス

データベースの縮小を計画するときは、次の情報を考慮してください。

• 縮小操作は、表の切り捨てや表の削除操作などの未使用スペースを作成する操作後に最も有効です。
• 大部分のデータベースは、通常の日常操作に利用できるいくつかの空きスペースを必要とします。 データベースを繰り返し縮小し、データベース サイズが再び大きくなることに気づくかもしれません。 この成長は、縮小されたスペースが通常の運用に必要であることを示しています。 このような場合、データベースの縮小を繰り返すことは無駄な操作です。
• 縮小操作は、データベース内のインデックスの断片化状態を保持せず、一般に断片化をある程度まで増加させます。 この結果は、データベースの縮小を繰り返さないもうひとつの理由です。
• 特定の要件がない限り、AUTO_SHRINK データベース オプションをオンに設定しないでください。

トラブルシューティング

行のバージョニングに基づく分離レベルの下で実行中のトランザクションによって縮小操作をブロックできることがあります。 たとえば、DBCC SHRINK DATABASE オペレーションが実行されたときに、行バージョニングに基づく分離レベルの下で実行されている大きな削除オペレーションが進行中である場合です。 このような状況が発生すると、縮小操作は削除操作の完了を待ってファイルを縮小します。 縮小操作が待機している間、DBCC SHRINKFILE および DBCC SHRINKDATABASE 操作は情報メッセージ（SHRINKDATABASE は 5202、SHRINKFILE は 5203）を出力します。 このメッセージは、最初の1時間は5分ごとに、その後は次の1時間ごとにSQL Serverエラー・ログに出力されます。 たとえば、エラー・ログに次のエラー・メッセージが含まれる場合：

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）より小さい数値が含まれている可能性があります。 この問題を解決するには、次のタスクのいずれかを実行します。

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

権限

固定サーバロール sysadmin または固定データベースロール db_owner のメンバーシップが必要です。 データベースを縮小し、空き領域の割合を指定する

次の例では、UserDBユーザーデータベースのデータおよびログファイルのサイズを縮小し、データベースの空き領域を10%にします

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. データベースを切り詰める

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

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Azure Synapse Analyticsデータベースを縮小する

DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10); 

参照

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Shrink a Database