收縮指定數據庫中的數據文件和日志文件的大小。
DBCC SHRINKDATABASE ( database_name | database_id | 0 [ , target_percent ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ) [ WITH NO_INFOMSGS ]
要收縮的數據庫的名稱或 ID。如果指定 0，則使用當前數據庫。
target_percent數據庫收縮后的數據庫文件中所需的剩余可用空間百分比。
NOTRUNCATE通過將已分配的頁從文件末尾移動到文件前面的未分配頁來壓縮數據文件中的數據。target_percent 是可選參數。
文件末尾的可用空間不會返回給操作系統，文件的物理大小也不會更改。因此，指定 NOTRUNCATE 時，數據庫看起來未收縮。
NOTRUNCATE 只適用於數據文件。日志文件不受影響。
TRUNCATEONLY將文件末尾的所有可用空間釋放給操作系統，但不在文件內部執行任何頁移動。數據文件只收縮到最近分配的區。如果與 TRUNCATEONLY 一起指定，將忽略 target_percent。
TRUNCATEONLY 只適用於數據文件。日志文件不受影響。
WITH NO_INFOMSGS取消嚴重級別從 0 到 10 的所有信息性消息。
若要收縮特定數據庫的所有數據和日志文件，請執行 DBCC SHRINKDATABASE 命令。若要一次收縮一個特定數據庫中的一個數據或日志文件，請執行 DBCC SHRINKFILE 命令。
若要查看數據庫中當前的可用（未分配）空間量，請運行 sp_spaceused。
可在進程中的任一點停止 DBCC SHRINKDATABASE 操作，任何已完成的工作都將保留。
收縮后的數據庫不能小於數據庫的最小大小。最小大小是在數據庫最初創建時指定的大小，或是使用文件大小更改操作（如 DBCC SHIRNKFILE 或 ALTER DATABASE）顯式設置的最后大小。例如，如果數據庫最初創建時的大小為 10 MB，后來增長到 100 MB，則該數據庫最小只能收縮到 10 MB，即使已經刪除數據庫的所有數據也是如此。
運行 DBCC SHRINKDATABASE 而不指定 NOTRUNCATE 選項或 TRUNCATEONLY 選項等價於帶 NOTRUNCATE 運行 DBCC SHRINKDATABASE 操作，然后再帶 TRUNCATEONLY 運行 DBCC SHRINKDATABASE 操作。
要收縮的數據庫不必在單用戶模式下；其他的用戶仍可以在數據庫收縮時對其進行工作。這也包括系統數據庫。
不能在備份數據庫時收縮數據庫。反之，也不能在數據庫執行收縮操作時備份數據庫。
DBCC SHRINKDATABASE 的工作原理
DBCC SHRINKDATABASE 以每個文件為單位對數據文件進行收縮。然而，DBCC SHRINKDATABASE 在對日志文件進行收縮時，它將視為所有的日志文件都存在於一個連續的日志池中。文件始終從末尾開始收縮。
假設名為 mydb 的數據庫有一個數據文件和兩個日志文件。數據文件和日志文件分別是 10 MB，並且數據文件包含 6 MB 數據。
對於每個文件，數據庫引擎都會計算一個目標大小。這就是文件將要收縮到的大小。將 target_percent 與 DBCC SHRINKDATABASE 一起指定時，數據庫引擎計算的目標大小是收縮后文件中的 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％。因為所要求的可用百分比加上數據文件占用的當前百分比大於 100%（多出 10%），所以任何大於 30 的 target_size 都不會收縮此數據文件。
對於日志文件，數據庫引擎使用 target_percent 來計算整個日志的目標大小；因此，target_percent 是收縮操作后日志中的可用空間大小。之后，整個日志的目標大小轉換為每個日志文件的目標大小。
DBCC SHRINKDATABASE 嘗試立即將每個物理日志文件收縮到其目標大小。如果虛擬日志中的所有邏輯日志部分都沒有超出日志文件的目標大小，則該文件將成功截斷，DBCC SHRINKDATABASE 完成且不顯示任何消息。但是，如果部分邏輯日志位於超出目標大小的虛擬日志中，則數據庫引擎將釋放盡可能多的空間，並發出一條信息性消息。該消息說明需要執行哪些操作來將邏輯日志移出位於文件末尾的虛擬日志。執行該操作以后，DBCC SHRINKDATABASE 可用於釋放剩余空間。有關詳細信息，請參閱收縮事務日志。
因為日志文件只能收縮到虛擬日志文件邊界，所以不可能將日志文件收縮到比虛擬日志文件更小（即使現在沒有使用該文件）。虛擬日志文件的大小在創建或擴展這些日志文件時由數據庫引擎動態選擇。有關虛擬日志文件的詳細信息，請參閱事務日志物理體系結構。
最佳做法
當您計划收縮數據庫時，請考慮以下信息：
-
在執行會產生許多未使用空間的操作（如截斷表或刪除表操作）后，執行收縮操作最有效。
-
大多數數據庫都需要一些可用空間，以供常規日常操作使用。如果反復收縮數據庫並注意到數據庫大小變大，則表明收縮的空間是常規操作所必需的。在這種情況下，反復收縮數據庫是一種無謂的操作。
-
收縮操作不會保留數據庫中索引的碎片狀態，通常還會在一定程度上增加碎片。這是不要反復收縮數據庫的另一個原因。
-
除非有特定要求，否則不要將 AUTO_SHRINK 數據庫選項設置為 ON。
故障排除
在基於行版本控制的隔離級別下運行的事務可能會阻塞收縮操作。例如，執行 DBCC SHRINK DATABASE 操作時，如果在基於行版本控制的隔離級別下運行的大型刪除操作正在進行中，則收縮操作將等到刪除操作完成才會收縮文件。出現這種情況時，DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 操作會在第一個小時每五分鍾將信息性消息（對於 SHRINKDATABASE 為 5202，對於 SHRINKFILE 為 5203）輸出到 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 動態管理視圖中的 transaction_sequence_num 或 first_snapshot_sequence_num 列包含值 15。如果該視圖中的 transaction_sequence_num 或first_snapshot_sequence_num 列包含的數字小於收縮操作完成的上一事務 (109)，則收縮操作將等待這些事務完成。
若要解決此問題，請執行下列任務之一：
-
終止阻塞收縮操作的事務。
-
終止收縮操作。將保留任何已完成的工作。
-
不執行任何操作，並允許收縮操作等到阻塞事務完成。
有關 SQL Server 錯誤日志的詳細信息，請參閱查看 SQL Server 錯誤日志。
要求具有 sysadmin 固定服務器角色或 db_owner 固定數據庫角色的成員身份。
要求具有 sysadmin 固定服務器角色或 db_owner 固定數據庫角色的成員身份。