DBCC SHRINKFILE

收縮相關數據庫的指定數據文件或日志文件大小。

語法

DBCC SHRINKFILE
    ( { file_name | file_id }
        { [ ,target_size ]
            | [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ] 
        }
    )

參數

file_name： 是已收縮文件的邏輯名稱。文件名必須符合標識符的規則。有關更多信息，請參見使用標識符。

file_id：　　是要收縮的文件的標識 (ID) 號。若要獲得文件 ID，請使用 FILE_ID 函數或在當前數據庫中搜索 sysfiles。

target_size：是用兆字節表示的所要的文件大小（用整數表示）。如果沒有指定，DBCC SHRINKFILE 將文件大小減少到默認文件大小。

如果指定 target_size，DBCC SHRINKFILE 將試圖將文件收縮到指定大小。將要釋放的文件部分中的已使用頁將重新定位到保留的文件部分中的可用空間。

　　例如，如果數據文件為 10MB，則帶有 target_size 為 8 的 DBCC SHRINKFILE 將導致文件最后 2 MB 中所有已用頁重新分配到文件前 8 MB 中的任何可用槽中。

　　DBCC SHRINKFILE 不會將文件收縮到小于存儲文件中的數據所需要的大小。例如，如果使用 10MB 數據文件中的7 MB，帶有 target_size 為 6 的 DBCC SHRINKFILE 語句只能將該文件收縮到 7 MB，而不能收縮到 6 MB。

EMPTYFILE：將所有數據從指定文件中遷移到同一文件組中的其它文件。Microsoft® SQL Server™ 不再允許將數據放在用于 EMPTYFILE 選項的文件上。該選項允許使用 ALTER DATABASE 語句除去文件。

NOTRUNCATE ：導致將釋放的文件空間保留在文件中。

　　當與 target_size 一起指定 NOTRUNCATE 時，釋放的空間不會釋放給操作系統。

　　DBCC SHRINKFILE 的唯一影響是將已使用的頁從 target_size 行上面重新定位到文件的前面。當未指定 NOTRUNCATE 時，所有釋放的文件空間返回給操作系統。

TRUNCATEONLY：導致文件中的任何未使用的空間釋放給操作系統，并將文件收縮到上一次分配的大小，從而減少文件大小，而不移動任何數據。不嘗試將行重新定位到未分配頁。如果使用 TRUNCATEONLY，將忽略 target_size。

【注意事項】

（1）要切換到被收縮文件所在數據庫,use db

DBCC SHRINKFILE 適用于當前數據庫中的文件。

將上下文切換到數據庫，以發出引用該特定數據庫中文件的 DBCC SHRINKFILE 語句。有關更改當前數據庫的更多信息，請參見 USE。

所生成的數據庫不能比 model 數據庫更小。

使用 DBCC SHRINKFILE 以將文件減小到比其最初創建時更小。之后，文件的最小大小重置為新指定的大小。

若要刪除在文件中可能出現的任何數據，請在執行ALTER DATABASE 之前執行 DBCC SHRINKFILE(''''''''file_name'''''''', EMPTYFILE)。

（2）收縮時不用單用戶

要收縮的數據庫不必在單用戶模式下；收縮文件時，同時其他用戶可以在數據庫中工作。不必在單用戶模式下運行 SQL Server 以對系統數據庫進行收縮。

（3）收縮日志文件注意事項

對于日志文件，SQL Server 使用 target_size 以計算整個日志的目標大小；因此，target_size 是收縮操作完成后日志中的可用空間大小。

之后，整個日志的目標大小可以解釋為每個日志文件的目標大小。DBCC SHRINKFILE 嘗試立即將每個物理日志文件收縮至其目標大小。

如果虛擬日志中的所有邏輯日志部分都沒有超出日志文件的目標大小，該文件將成功截斷，DBCC SHRINKFILE 完成且不顯示任何消息。

然而，如果虛擬日志中的邏輯日志部分超出目標大小，則 SQL Server 釋放盡可能多的空間并發出一條消息。

該信息告訴您需要執行什么操作來移動文件末尾超出虛擬日志的邏輯日志部分。

執行完該操作后，可以重新發出 DBCC SHRINKFILE 命令以釋放剩余的空間。有關收縮事務日志的更多信息，請參見收縮事務日志。

因為日志文件只能收縮到虛擬日志文件邊界，所以不可能將日志文件收縮到比虛擬日志文件更小（即使現在沒有使用該文件）。

例如，可以將數據庫的 1 GB 日志文件收縮到只有 128 MB。有關截斷的更多信息，請參見截斷事務日志。有關確定虛擬日志文件大小的更多信息，請參見虛擬日志文件。

（4）收縮結果集中列

下表描述結果集內的列。

DbId：SQL Server 試圖收縮的文件的數據庫標識號。FileIdSQL Server 試圖收縮的文件的文件標識號。

　　　　CurrentSize文件當前占用的 8KB 頁數。MinimumSize文件可以占用的最小 8KB 頁數。這與文件的最小大小或最初創建時的大小相對應。UsedPages文件當前使用的 8KB 頁數。EstimatedPagesSQL Server 估計文件能夠收縮到的 8KB 頁數。

權限：DBCC SHRINKFILE 權限默認授予 sysadmin 固定服務器角色或 db_owner 固定數據庫角色的成員且不可轉讓。

示例：

下例將 UserDB 用戶數據庫中名為 DataFil1 的文件收縮到 7 MB。這個名稱是邏輯名稱

USE UserDB
GO

DBCC SHRINKFILE (DataFil1, 7)
GO

【收縮數據文件、日志文件的影響】

（1）收縮數據文件的影響

數據庫使用數據文件（擴展名是mdf 或 ndf)來存儲數據，使用日志文件（擴展名是ldf）來存儲事務日志，通常情況下，數據文件會持續增長，不會自動釋放空閑空間，這樣會導致硬盤空間耗盡。

如果一個數據庫的文件有很多空閑空間，收縮數據庫文件是一種解決硬盤空間緊張的直接方式。

原理與影響：

　　在SQL Server中，我們可以使用 DBCC ShrinkFile命令收縮數據文件，該命令首先將文件尾部的區（extent）移動到文件的開頭，文件結尾的空閑的硬盤空間被釋放給操作系統。

　　這種操作就像截斷將文件的尾部一樣，這種方式不需要消耗很多IO就能釋放空間；

　　但是，如果空閑部分不在文件末尾時，收縮操作必須掃描數據文件，并對正在讀取的頁面加鎖，把文件末尾的區移動到文件開頭，這是一個IO密集型的操作，影響數據庫的性能；

　　1、收縮操作不是一個獨占行為，在做文件收縮時，其他用戶仍然可以對數據庫進行讀寫操作。

　　2、收縮會鎖表，會阻塞

　　3、在任意一個時間點停止dbcc shrinkfile命令，任何已經完成的工作都將保留。

建議：

　　收縮 數據庫 是非常耗費server性能的操作，如果沒有必要不要收縮

　　收縮 無非就是把已經分配給數據庫文件空間收回來，但是，收縮的時候 要移動數據頁，而且可能造成大量的碎片，影響性能。

　　日志收縮和數據文件收縮不一樣，日志中的虛擬文件狀態 只有 在可復用 時候  才能收縮。

　　而且 凡是有活動的日志的日志虛擬文件都是活動的不能收縮。

（2）收縮日志文件的影響

日志文件收縮， 回收磁盤空間。
　　數據文件 根據設計  設計的大小，一般情況不用收縮，收縮可能帶來性能的問題。

日志
　　如果 選擇的日志恢復模型是完全，如果沒有日志截斷，日志增長的很大，
建議
　　備份日志。
　　　　backup log db to disk=''''''''備份設備''''''''
　　截斷日志
　　　　backup log db with no_log
　　然后收縮。
　　　　dbcc shrinkfile(2,10)

  原理參考：https://www.cnblogs.com/gallen-n/archive/2017/03/15/6555283.html

【最佳實踐步驟-收縮數據文件】

1、實際工作中收縮數據文件的情況比收縮庫的情況多，不建議直接收縮數據庫

2、收縮很容易出現等待，收縮會話對應 sys.sysprocesses 的字段 waitresource 值類似為15:1:4700649，sys.sysprocesses 的字段  lastwaittype 值為PAGEIOLATCH_SH或PAGEIOLATCH_EX等

3、收縮數據文件時，不要一次性全部收縮。 可以每次收縮5G左右，比如DataFile1有32G，則每次收縮如下

4、數據文件的可用空間可以結合sys.master_files 和 FILEPROPERTY(name,''''''''SpaceUsed'''''''') 來查看

5、收縮的100%進度可以通過 sys.dm_exec_requests 的字段 percent_complete 來看

6、收縮完后，記得重建索引

alter index all on table_name rebuild   with(online=on) 這個參數加了不影響線上

【最佳實踐步驟-收縮日志文件】

參考："http://www.yesky.com/imagesnew/software/tsql/ts_dbcc_8b51.htm"