记得我们前面说的，在读取页计算校验和时出错，这既可能是被写入持久化存储的页本身出错，也可能是在页被读取的过程中出错，此时SQL Server会尝试从IO子系统中再次读取该页，最多可能是4次尝试，如果在4次尝试过程中校验和通过，则会是825错误，否则是824错误。这里要注意，与823和824错误不同的是，825错误是一个等级仅为10的信息。
因此，由于有固定的错误编号，因此可以在SQL Server Agent中对823和824设置警报。
备份CheckSum
上述页CheckSum只有在页被使用时才会被校验页的正确性。在备份数据库时，可以指定CheckSum选项来使得备份读取的页也计算校验和，从而保证了被备份的数据库是没有损坏的。在图3的备份选项我们可以注意到这两条：
图3.CheckSum和Continue_After_Error选项
如果启用了CheckSum，当备份过程中发现了页校验和错误时，就会终止备份，而启用了Continue_After_Error选项的话，在检测到校验和错误时，仍然继续从而使得备份成功。
备份如果启用了CheckSum选项，除去检测每一页的校验和之外，还会在备份完成后，对整个备份计算校验和并存储于备份头中。
此外，对于备份，我们还可以通过Restore Verifyonly with CheckSum来验证备份，来保证备份的数据没有被损坏。
DBCC CheckDB
前面提到SQL Server发现错误的方法有两种，分别为在读取页时和在备份时（本质上也是读取页）。但如果我们希望对于数据一致性的检查更加的激进，那我们应该定期使用CheckDB来检查数据的一致性，而不至于在生产时间数据被读取时才能发现错误。
CheckDB命令会对整个数据库做所有的一致性检查。当检查对象是Master数据库时，CheckDB还会检查ResourceDB。
CheckDB最简单的用法如代码清单2所示，在当前数据库上下文中直接执行CheckDB，将会检查当前数据库中所有的一切。
DBCC CHECKDB
代码清单2.CheckDB最简单的用法
CheckDB命令在企业版中会使用多线程来进行，会对整个数据库进行一致性检查，在该过程中，使用了内建数据库快照的方式进行，因此不会造成阻塞，但CheckDB会消耗大量的CPU、内存和IO。因此CheckDB要选择在维护窗口时间或是系统闲时进行。
默认情况下，CheckDB命令会将输出所有的信息，但通常我们并不关心这些信息，而是只关心错误信息，因此实际中通常给DBCC指定不显式信息的参数，如代码清单3所示。
DBCC CHECKDB WITH NO_INFOMSGS;
代码清单3.CheckDB通常搭配No_InfoMsgs参数
实际上，CheckDB是一套命令的汇总，CheckDB会依次检查下述内容：
初次检查系统表
分配单元检查（DBCC CHECKALLOC）
