SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能

误区 #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个误区