探索中国CIO人才现状 | 第四季调研报告
DBA 五大致命失误:数据损坏了,你知道不知道?
2015-09-23  来源:techtarget

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

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

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

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

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