誤區 #9: 數據庫文件收縮不會影響性能
錯誤!
收縮數據庫文件唯一不影響性能的情況是文件末尾有剩余空間的情況下，收縮文件指定了TruncateOnly選項。
收縮文件的過程非常影響性能，這個過程需要移動大量數據從而造成大量IO，這個過程會被記錄到日志從而造成日志暴漲，相應的，還會占去大量的CPU資源。
不僅在收縮的過程中影響性能，并且在文件收縮之后同樣影響應能，收縮產生的大量日志會被事務日志傳送，鏡像，復制能操作重復執行。而空間不夠時，文件還需要填0初始化從而影響性能（除非你開啟的不用填零初始化的選項）。
這還不算最糟，最糟的結果是文件收縮造成了大量的索引碎片，對于scan操作來說這個碎片影響性能。
不幸的是，收縮數據庫的代碼不是我寫的（如果要是我寫的話，我一開始就不會允許這種機制的）所以我們唯一能做的就是接受這種操作。
如果你想找到替代數據庫文件收縮的方式，請看這篇博文：Why you should not shrink your data files,或者是一開始你就對文件做好規劃:Importance of data file size management。還有這篇:TGIF Time Warp.
孩子，記住這一點:
- 數據文件收縮是邪惡的
- 收縮數據庫更加邪惡
- 自動收縮那簡直就是十惡不赦了
簡單的對收縮說NO就可以讓我們永遠遠離其造成的煩惱。
您可能感興趣的文章:- SQL Server誤區30日談 第29天 有關堆碎片的誤區
- SQL Server誤區30日談 第28天 有關大容量事務日志恢復模式的誤區
- SQL Server誤區30日談 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
- SQL Server誤區30日談 第26天 SQL Server中存在真正的“事務嵌套”
- SQL Server誤區30日談 第25天 有關填充因子的誤區
- SQL Server誤區30日談 第24天 26個有關還原(Restore)的誤區
- SQL Server誤區30日談 第23天 有關鎖升級的誤區
- SQL Server誤區30日談 第22天 資源調控器可以調控IO
- SQL Server誤區30日談 第21天 數據損壞可以通過重啟SQL Server來修復
- SQL Server誤區30日談 第20天 破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈
- SQL Server誤區30日談 第19天 Truncate表的操作不會被記錄到日志
- SQL Server誤區30日談 第18天 有關FileStream的存儲，垃圾回收以及其它
- SQL Server誤區30日談 第17天 有關頁校驗和的誤區
- SQL Server誤區30日談 第16天 數據的損壞和修復
- SQL Server誤區30日談 第15天 CheckPoint只會將已提交的事務寫入磁盤
- SQL Server誤區30日談 第14天 清除日志后會將相關的LSN填零初始化
- SQL Server誤區30日談 第13天 在SQL Server 2000兼容模式下不能使用DMV
- SQL Server誤區30日談 第12天 TempDB的文件數和需要和CPU數目保持一致
- SQL Server誤區30日談 第11天 鏡像在檢測到故障后瞬間就能故障轉移
- SQL Server誤區30日談 第10天 數據庫鏡像在故障發生后 馬上就能發現
- SQL Server誤區30日談 第8天 有關對索引進行在線操作的誤區
- SQL Server誤區30日談 第7天 一個實例多個鏡像和日志傳送延遲
- SQL Server誤區30日談 第6天 有關NULL位圖的三個誤區
- SQL Server誤區30日談 第5天 AWE在64位SQL SERVER中必須開啟
- SQL Server誤區30日談 第4天 DDL觸發器就是INSTEAD OF觸發器
- SQL Server誤區30日談 第3天 即時文件初始化特性可以在SQL Server中開啟和關閉
- SQL Server誤區30日談 第2天 DBCC CHECKDB會導致阻塞
- SQL Server誤區30日談 第1天 正在運行的事務在服務器故障轉移后繼續執行
- SQL Server誤區30日談 第30天 有關備份的30個誤區
