SQL Server误区30日谈 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
误区 #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
- SQL Server误区30日谈 第12天 TempDB的文件数和需要和CPU数目保持一致
- SQL Server误区30日谈 第11天 镜像在检测到故障后瞬间就能故障转移
- SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现
- SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能
- 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个误区