注:Robert L Davis是微软的高级数据库管理员和专家,同时是《SQL Server》杂志的撰稿人,并合著《Pro SQL Server 2008 Mirroring》一书。
每个人都会犯错,DBA也不例外。不过DBA犯错时,通常他们也是第一个发现错误,并立刻修正错误。但,有些错误是不可原谅的,因为可能给企业造成不可挽回的损失。我将陆续介绍DBA的5大失误,这些失误会危及到数据的可恢复性、完整性和安全性,是不可原谅的错误,DBA为此可能会付出丢掉工作的代价。
DBA的首要重点工作是备份。这一点,再如何强调其重要性,都不为过。就算万事出错,你都应该确保备份是任何灾难事件中最后的一根稻草。我听到或遇到太多类似的事件,发生意外事件时,发现备份工作没有做,或者备份被损坏,无法恢复。这可能导致公司采取严厉措施规定什么样数据必须保存,并得处理数据丢失的严重后果。没有按照规定进行可靠的备份可能会让你丢掉工作。
在完美的数据世界中,DBA应该了解对恢复事件和数据丢失的要求。这两个要求通常被称为恢复时间目标(Recovery Time Objective,RTO)和恢复点目标(Reovery Point Objective,RPO),用来设计灾难恢复计划(和相应的的备份计划),以支持数据恢复。
在灾难发生时,RTO是允许你宕机的时间,RPO是允许你丢失的数据量。DBA的目标应该是尽可能将数据流失接近零。在制定灾难恢复计划的备份计划时,你应该假设所有其他级别的保护都失败,从备份中还原是你防御的最后一道防线。
如果你真的走到这最后一道防线,最后的好备份就是你将丢失的数据量。这将帮助你确认备份的频率,如果数据丢失量的要求低,你就需要频繁备份。你应该高频率备份的唯一备份类型是日志备份。这就意味要么是完整恢复模式(full recovery model),或大容量日志恢复模式(bulk-logged recovery model)。
有可靠的备份不仅仅意味着只是备份,而是指知道备份可以恢复,知道何时进行恢复。这就是测试备份的用武之地了。作为最低限度,你应该使用BACKUPVERIFYONLY命令来测试备份是否可恢复。
除了验证备份之外,我还会强烈建议使用CHECKSUM选项,对所有的备份和恢复进行验证。CHECKSUM选项执行额外的检查,可能时会确定数据库是否已损坏。如果额外的检查发现数据损坏,备份操作将失败,并提醒数据已损坏。此外,它还会对整个备份文件执行校验,这将帮助你检测是否备份文件是在创建后被损坏的。
对整个备份文件进行最后的CHECKSUM操作,最大的好处是如果备份文件本身已损坏,那么对该文件进行恢复会立刻失败。这对非常大型的数据库而言,尤为重要。因为一个还原操作可能需要花数小时。如果备份文件已经损坏,它在页头有一个额外的校验值,那么效验将在恢复操作开始之时重新计算,并很快失败。虽说找出备份文件受损的恢复时间并非好事,但远远好过经过几个小时的恢复运行才发现文件受损。
DBA能够确保备份可恢复的最好方法就是通过执行实际的恢复进行测试。理想情况下,我更喜欢结合使用自动修复备份(以确保它们有效)和运行灾备训练(演习停机情况下,DBA运行整个恢复过程)。规划和实践是当实际灾难发生时,帮助你达到恢复需求的关键所在。
我想说的是,DBA应该做的第一件事情和最后一件事情都是备份。如果我遇到新的服务器或环境,我做的第一件事情就是确保所有的服务器都有备份,并成功运行。之后,我会重新检查备份情况,基于实际的RPO和RTO需求制定一个灾难恢复计划。如果DBA没有做到第二步,还算情有可原,但是没有可靠的备份就是一个无可饶恕的失误。假如发生灾难或意外,DBA却没有可靠的备份,恐怕工作难保。