数据损坏随时可能发生在任何人身上，没有任何办法可保证它不会发生。DBA的职责是，尽量尽早发现损坏，并及时处理。我在之前的文章《DBA 五大致命失误：你的数据可靠吗？》中提到过，数据受损是灾难事件中的一部分，现在单独拿出来讨论，希望大家能够重视它的重要性。大多数DBA没有丰富经验如何处理损坏，因为这并不是定期会遇到的问题。真正发生时，关键措施之一就是迅速找到损坏的数据所在。如果不这样做，可能会导致无法从损坏之处进行恢复，并且不丢失数据，相反，可能有时会丢失大量数据。

SQL Server提供了很多内置的方法帮助检测损坏。 我在之前一文介绍了用于备份和恢复的CHECKSUM选项，并在以后会介绍页校验（page verification）选项。现在要介绍的是使用DBCC CHECKDB命令或其他DBCC CHECK命令进行基本的数据完整性检查。

DBA再忙，但至少应该定期检查所有数据库的完整性。经常被DBA忽视的是“定期检查”。恢复受损数据不丢失任何数据，并将停机时间最小化，这就意味着要对部分或整个数据库进行备份。但是，如果你备份的数据库已经受损（没有使用CHECKSUM选项），那你得到的就是受损的备份。如果这个受损备份长时间没有被发现，你不太可能有一个好的、未损坏的备份，并能够把数据库恢复到当前时间。

即使是在磁带上长期存储，你可能也需要及时检查备份是否有损坏。也有可能你并没有从受损点之后的所有日志文件，以致你无法把数据库恢复至当前。这可能意味着相当多的数据会丢失。至少，如果通过异地存储进行恢复，可能造成长时间的宕机。最糟的情况是，大多数（或全部）的数据可能丢失。曾有过这样的公司因为发生类似的事件，造成最后公司倒闭。

虽然DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS这个选项操作简单，但自动修复损坏应该作为最后不得已的选择。这个选项通过重新分配受损页进行修复，但如果数据页一旦消失了，就永久消失了。在无法快速查找损坏，也没有未受损的有效备份时，很多DBA可能会采用这种方法。但，这是DBA很严重的疏忽之处，不及时检测受损数据，会让自己时刻面临被炒的危险。