SHRINKFILE 最佳實踐和經驗
序言：總的來說，這是一個很大的禁忌，但相信我，在真正需要空間的情況下很少見。例如 Express Edition 限制為 10GB。想像一下，您發現通過數據類型轉換（blob 列）可以釋放大量空間。但在那之後，DB 文件的大小仍然和我們知道的一樣，並且 10GB 的限制也沒有神奇地改變。所以需要某種 SHRINK。那是一個例子。
在我的測試環境中，我執行了：
DBCC SHRINKFILE (DBFile, NOTRUNCATE) DBCC SHRINKFILE (DBFile, TRUNCATEONLY)這就是訣竅（我知道這會最大限度地減少可用空間，在現實世界中我會留下可用空間）。花了好幾個小時才完成。正如我們所知，它是一個單執行緒程序奇怪的行為 DBCC Shrinkfile，“它作為一系列非常小的系統事務工作，因此沒有什麼可以回滾的。” - 保羅蘭德爾http://www.sqlservercentral.com/Forums/Topic241295-5-1.aspx>。我們也知道它會嚴重破壞索引碎片<http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-data-files/我可以確認。儘管在http://www.karaszi.com/SQLServer/info_dont_shrink.asp中有所描述，但我沒有遇到日誌文件增長
我發布了一些
INDEX REBUILD，REORGANIZE並且那些在幾秒鐘內就完成了。我的問題：
- 如果我可以在幾秒鐘內縮小後修復索引碎片，那麼縮小有什麼大不了的？我不明白。在 DBA stackexchange 上，“縮小”主題 ( https://dba.stackexchange.com/tags/shrink/info ) 說“幾乎可以對 SQL Server 數據庫做的最糟糕的事情。簡而言之：它犧牲了性能來獲得空間。” plus 指的是另一篇關於它的流行文章。但是可以修復索引碎片。
- 為什麼我沒有遇到任何日誌文件增長？
- 如果在空間釋放操作之後首先重建索引會怎樣。那可以代替第一個
DBCC SHRINKFILE (DBFile, NOTRUNCATE)，所以我只需要DBCC SHRINKFILE (DBFile, TRUNCATEONLY)嗎？我有一種感覺，這兩者在不同的邏輯層面上工作，但我不得不問這個。底線：我保證我不會定期收縮或做任何事情。但這是一個上限被擊中並需要收縮的情況。
回答我的第二個問題：我沒有遇到事務日誌文件增長，因為我在開發人員測試環境中擺弄。事務日誌文件會在生產環境中增長（假設完全恢復模式）。你也應該在你的測試環境中模仿它。tr 日誌文件的增長實際上大於您可以在數據庫文件中釋放的空間。最後，您不僅要縮小數據庫文件，還要縮小事務日誌（如何以及何時這樣做取決於恢復模型）。我看到的生產環境已經搞砸了索引碎片，它可以做得更好。我的腳本重新索引碎片級別高於 30% 的每個索引。
為了應對增長，您可能必須在進行千載難逢的轉換時從完全恢復切換到簡單恢復。但這會破壞備份鏈。
回答我的第三個問題：在 DB 文件收縮後重新索引/索引重建，因為收縮會弄亂索引碎片。
我還沒有試驗過所有這些如何影響查詢統計資訊。
重新索引腳本：請參閱TechNet sys.dm_db_index_physical_stats (Transact-SQL)的範例D。關於增量收縮的文章，將引出其他有價值的內容：http ://www.mssqltips.com/sqlservertip/3178/incrementally-shrinking-a-large-sql-server-data-file-using-powershell
如果你想：
- 忽略來自在 SQL Server 方面有豐富經驗的非常聰明的人的所有警告；
- 假設因為在這種情況下您沒有經曆日志增長，並且在這種情況下修復碎片很快並且不會導致任何進一步的增長，情況總是如此；和，
- 不確認這個增長/收縮/增長/收縮週期對查詢時間有任何影響；
前進。既然你說你只會在極少數情況下這樣做，我不確定你在這裡尋找什麼答案。你想要一個大大的讚，你可以忽略你讀過的所有東西並擲骰子嗎？
我會建議至少一件事：如果你有 10GB 的數據，就會在 Express 中達到 10GB 的限制。您可以通過刪除數據文件中的數據（或將數據分散到多個數據庫）來避免這種情況。如果您在數據文件中釋放一堆空間，該空間將被重複使用（如果您刪除了一個表，這將是自動的；如果您刪除了行或更改了列結構，您將需要重建 - 這至少也會暫時佔用一些空間）。因此，如果您釋放文件中的 5GB 數據，僅僅因為文件為 9GB 並不意味著如果添加 2GB 它將嘗試變為 11GB - 它會重用文件內部的空間，直到找不到更多空間為止。將文件縮小到 4GB，然後強制它增長以容納新數據將是一項更昂貴的操作。這就像洗一條已經乾淨的毛巾，你將用它來擦拭一團糟……