SQL Server误区:使用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 Q&A #26: Myths around causing corruption

更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/SQLServer/

时间: 2024-12-31 18:30:32

SQL Server误区:使用BACKUP ... WITH CHECKSUM可以替代DBCC CheckDB的相关文章

SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞_MsSql

误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁 这是错误的!     在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且-..     在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重

SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞

误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁 这是错误的! 在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且-.. 在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重写了DBCC C

SQL Server误区30日谈 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB_MsSql

误区 #27:使用BACKUP ... WITH CHECKSUM可以替代DBCC CheckDB错误    乍一看,由于BACKUP WITH CHECKSUM会检测所有分配出去的页的校验和的值,这个误区貌似是这么回事,但实际上并不是这么回事,原因如下:    由SQL Server 2000或是更早版本升上来的数据库page checksums必须开启,在开启后,并不是数据库中所有的页都会被叫上页校验和,当页损坏发生时,IO系统可不会区分损坏的页是有页校验和还是没有校验和的.所以使用BACK

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

SQL Server误区30日谈 第30天 有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区:有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区:26个有关还原(Restore)的误区

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步. 事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. Myth #24:26个有关还原(Restore)的误区 都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点 当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到

SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区_MsSql

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

SQL Server误区:在破坏日志备份链后需要完整备份来重新开始日志链

误区 #20:在破坏日志备份链之后,需要一个完整备份来重新开始日志链 错误 事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有过日志备份的话,那就从上一次完整备份开始).有好几种类型的操作会中断事务日志的连续性,也就是说除非重新开始新的日志链,SQL Server无法再进行日志备份.下面这几种操作都有可能引起日志链断裂: 由完整恢复模式或大容量事务日志恢复模式转为简单恢复模式 从数据库镜像进行恢复 备份日志时指定了NO_LOG 或 WITH TRUNCATE_ONLY(还好在S