编者按：罗伯特·L·戴维斯是微软高级数据库管理员和专家，《SQL Server》杂志撰稿人，与人合着《Pro SQL Server 2008 Mirroring》本书。数据损坏随时可能发生在任何人身上，并且不能保证它不会发生。DBA的职责是尽早发现损害并及时处理。我在之前的文章中提到数据损坏是灾难事件的一部分，现在单独讨论，希望大家能够重视它的重要性。大多数DBA没有处理损坏的经验，因为这不是经常遇到的问题。当它确实发生时，关键步骤之一是快速定位损坏的数据。如果不这样做，可能会导致无法从损坏中恢复并且不会丢失数据，或者有时可能会丢失大量数据。SQLServer提供了许多内置方法来帮助检测损坏。上一篇介绍了备份和恢复的CHECKSUM选项，后面会介绍页面验证（pageverification）选项。现在介绍使用DBCCCHECKDB命令或其他DBCCCHECK命令的基本数据完整性检查。不管DBA有多忙，他至少应该定期检查所有数据库的完整性。DBA经常忽视的是“定期检查”。在不丢失任何数据且停机时间最短的情况下恢复损坏的数据意味着对部分或整个数据库进行备份。但是，如果您备份的数据库已损坏（没有CHECKSUM选项），那么您得到的是损坏的备份。如果这个损坏的备份在很长一段时间内都未被发现，那么您不太可能拥有一个良好的、未损坏的备份并且能够将数据库恢复到当前时间。即使在磁带上进行长期存储，您也可能需要检查备份是否损坏。也有可能您没有从损坏点开始的所有日志文件，因此您无法将数据库恢复到现在。这可能意味着大量数据丢失。至少，如果在异地进行恢复，可能会导致停机时间延长。在最坏的情况下，大部分（或全部）数据可能会丢失。曾经有这样一家公司因为类似的事件，导致***公司倒闭。尽管DBCCCHECKDBWITHREPAIR_ALLOW_DATA_LOSS选项操作简单，但自动修复损坏应该作为最后的手段。该选项通过重新分配损坏的页面来修复，但如果数据页消失一次，它就绝对消失了。很多DBA在不能快速找到损坏的地方，而且没有未损坏的有效备份时，可能会使用这种方法。然而，这是DBA非常严重的疏忽。未能及时检测到损坏的数据将使您随时处于被解雇的危险之中。
