DBCC SHIRNKFILE(Data_File, 0) 命令不應該將數據文件縮小到最後分配的範圍嗎？
我有一個帶有以下參數的數據文件：
當我執行**DBCC SHRINKFILE (DBAtools_data,1)**時，它顯示以下結果：
我同意。我的抱怨是關於**DBCC SHRINKFILE (DBAtools_data,0)**命令。當我執行它時，沒有任何變化。我認為它會將數據文件縮小到最後分配的範圍，換句話說，結果與上面相同。有人可以為我澄清一下嗎？
好吧，我想我找到了原因，儘管我從 BOL 中找不到任何相關資訊。很明顯，任何不同於 0（在我的情況下為 1）的東西都會嘗試將文件縮小到該值，並且正如 BOL 所述，它還將嘗試將文件的大小重置為該值（1 MB）。如果為 0，它只會在創建時將數據文件縮小並調整為文件的初始大小。該值（minSize）儲存在文件的標題頁中，我使用未記錄的 DBCC Page 命令找到了它：
DBCC TRACEON(3604) GO DBCC PAGE('DBAtools', 1, 0, 3) WITH TABLERESULTS我們可以得出結論，DBCC SHRINKFILE (Data_File, 0) 命令將數據文件收縮到創建數據文件時指定的值。換句話說 DBCC SHRINKFILE (Data_File, 0) 與 DBCC SHRINKFILE (Data_File) 相同
由於無法訪問 SQL Server 的原始碼，我們只能猜測。所以，
編輯：0 表示根據頁眉縮小到初始大小。我的猜測，它意味著虛擬，下面，是不正確的。
設置投機模式
0 沒有意義。如果您想刪除該文件，您可以使用 EMPTYFILE 選項。即，您為什麼想要一個大小為 0 MB 的文件。
我剛剛做了一個測試，確實 0 意味著它什麼都不做。我們可以爭辯說錯誤消息會更好：“0 MB 不是有效的文件大小。”，或類似的東西。但顯然 MS 決定將 0 作為該命令的有效有效值並將其實現為虛擬對象。
設置投機模式關閉
我建議您向 MS 提出請求，以記錄 0 表示“虛擬”或行為更改，以便我們收到錯誤消息（不太可能發生）。