Q：我经常被问到SQL Server 2008中是否推荐使用CheckDB。 自从SQL Server 2005版本之后，SQL Server现在计算checksum来避免物理页损坏。但是根据我从没看到过有明确的说明声称CheckDB是不必要的。有相关的好地建议么？
A：
的确DATABASE PAGE AUDIT CHECKSUM的增加减少了部分经常执行CHECKDB的需求。历史数据也显示自从SQL Server 7.0以来存储引擎的质量有了显著的提升，进一步降低了使用CHECKDB的需要。
但是，类似checksum的功能只能保证写到磁盘的内容和读回（read back）的内容完全一致，它不会验证CHECKDB设计时涉及的很多其他一致性问题。举个例子，CHECKDB会验证系统表的元数据（Metadata），页链接（page linkage），索引排序（index ordering）和其他方面。
所以该问题的答案是：该需求自从SQL Server 7.0之后减少了，另外一个原因是为了客户的使用方便。一个考虑严密的恢复计划包括完整恢复和checkdb来保证恢复计划的每个部分都能正常工作。例如您可能会拥有一个干净的数据库，进行备份和在其因备份媒介传输故障而损坏时恢复。SQL Server 2008的带checksum的备份特性在这种情况下就可以起效了。但数据库引擎不可能控制所有的方面，例如以下几种情况：
1. 曾经有一个case，症状为磁带驱动产生了位移偏离。可以成功备份，但恢复时无法读取磁带。在尝试恢复之前引擎都没有意识到硬件导致了问题的发生。客户的生产服务器损坏，却无法进行恢复，只能花费了十万美元请磁带恢复公司。
2. 内存和ECC错误率方面一大问题是仅更改了一个比特的内存传输。这就是SQL Server 2005为什么增加了对于缓存池的连续页扫描。该技术提供了当页在内存中时的checksum样本，以保证只读页不被类似的错误改变。但该技术也会有遗漏。曾经有一个case就是由该问题导致。某个主键上的值9被修改为19，导致了主键冲突。DBCC CHECKDB是唯一能在完成或差异备份之前检查出该问题的方法。
3. 类似ECC SQL Server的这个bug，但发生频率更高的是XPROC和COM组件的bug也可能导致类似的问题，例如XPROC中的代码错误地更新了内存。
4. 在过去的十年内我们关于存储的首要问题是旧读（从硬件缓存返回旧版本的页，而非磁盘上的最新版本的数据）。这通常不会导致checksum测试失败。有以下的场景：我的妻子在夫妻共同的帐户内存储了500美元，几分钟后我撤销了该操作。硬件的缓存还存在于我的妻子存储之前的状态。500美元的存储已经提交并写到了磁盘上，但硬件缓存没有更新。当我撤销时更新操作无法看见存入的500美元，错误地更新了该帐号。SQL Server可能不会直接意识到这个错误，导致逻辑事务的丢失。这就是SQL Server为什么增加了旧读检查样本。样本能有帮助，但不能彻底防止该情况的发生。对于这种情况，即使DBCC也不会捕捉到这个问题，但从事务日志的恢复会检查到该页被两次更新，但具有相同的LSN，而这是不允许的情况。
总结一下，我永远也不会说已经不再需要DBCC，您需要在需要的时候和从备份恢复时运行它。