误区 #27:使用BACKUP ... WITH CHECKSUM可以替代DBCC CheckDB 错误 乍一看，由于BACKUP WITH CHECKSUM会检测所有分配出去的页的校验和的值，这个误区貌似是这么回事，但实际上并不是这么回事，原因如下: 由SQL Server 2000或是更早版本升上来的数据库page checksums必须开启，在开启后，并不是数据库中所有的页都会被叫上页校验和，当页损坏发生时，IO系统可不会区分损坏的页是有页校验和还是没有校验和的。所以使用BACKUP ... WITH CHECKSUM就有可能导致一些损坏页不被发现，造成的后果…… 除此之外，还有一个问题是完整备份的时间间隔相对比较长，假如说一个月，而相对于DBCC CheckDB的最佳实践是一个礼拜，这导致WITH CHECKSUM不能替代CHECKDB。即使你每周都进行差异备份，但差异备份只会检测差异部分的页校验和。 最后一点，也是危害最大的一点,就是使用BACKUP WITH CHECKSUM选项不能发现内存中的页损坏。这是因为由于内存芯片或是WINDOWS进程导致内存中的页损坏，并且在这之后写回磁盘。这导致损坏页却有正常的校验和，只有使用DBCC CheckDB才能发现这类错误。 因此，说到底，你必须经常使用DBCC CHECKDB，如果对此你仍然心存疑问，请看我之前的一篇文章:CHECKDB From Every Angle: Consistency Checking Options for a VLDB。
扩展阅读:Search Engine QA #26: Myths around causing corruption
您可能感兴趣的文章:
SQL Server误区30日谈 第29天 有关堆碎片的误区
SQL Server误区30日谈 第28天 有关大容量事务日志恢复模式的误区
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
