对于数据库管理员来说，不可预测的灾难虽然让他们很头疼，但是并不可怕。可拍的是没有为可能发生的灾难做好相关的准备。以至于当灾难发生的时候素手无策。由于硬件故障、服务器被偷或者其他意外事故，数据库管理员很难避免。数据库管理员能够做的就是采取哪些措施来为未来可能发生的灾难最好准备。笔者在这方面虽然不能够说做的面面俱到，但是也算是做得不错了。笔者就在这里跟大家分享一下这方面的管理经验，帮助大家来应对这些不可预知的灾难。
措施一：定时的对备份文件进行测试。
为了在数据库出现故障的时候迅速利用备份文件进行恢复，数据库管理员往往会设计比较合理地备份策略。如在SQL Server数据库汇中，可以通过完全备份与差异备份相结合的策略来对数据库进行备份。这一步大部分数据库管理员都做的很好。但是他们只做到这一步而已。而很少有数据库管理员会对这些备份文件进行测试，看看能否利用这些备份文件进行顺利恢复。
笔者有一个朋友以前就犯过这个错误。他配制好数据库备份策略以后以为就万事大吉了。但是一次当数据库出现故障，利用这个备份文件恢复之后就出现了一些问题。在数据库中有些视图的列采用了中文名字，但是可能在数据部署的时候配置不当或者其他的原因，导致在恢复的过程中这些中文备注显示的是乱码;而字段名称或者视图名字中包含中文汉字的，则就无法正确恢复过去。还是这些内容不是很多，平时工作中又作了详细的工作笔记，为此发现这个问题后，马上可以重建这些视图。虽然这次事故最终没有造成很大的损失，但是也给我们数据库管理员提了一个醒。数据库备份之后并不是万无一失了。数据库管理员最好能够不定时的对备份文件进行测试，以确保这些备份文件的准确性;以及确保可以从这些备份文件中恢复需要的数据。
笔者现在给企业部署SQL Server数据库的时候，都会要求企业的数据库管理员至少每隔一个月需要对备份文件进行恢复测试。一方面用来测试这些备份文件的准确性，防止因为不正确的备份而造成无法挽回的损失。另一方面，也是锻炼企业数据库管理员对于数据库恢复的熟练程度，让他们能够在遇到数据库服务器故障的时候，能够在最短时间内恢复数据库软件。如果平时不怎么关注这个恢复过程的话，则这些数据库管理员一段时间没做的话，很可能都会还给笔者了。为此进行数据库备份文件的还原测试，即可以用来判断备份文件是否准确;也可以让企业数据库管理员熟悉还原流程。一举多得，数据库管理员要定时不定时的做好还原测试。
措施二：设计并运行一些基本的功能脚本。
作为数据库管理员来说，最悲惨的事情就是自己是最后一个知道问题的人。可能某些故障，如备份失败或者某个触发器无法正常运行，已经发生了很长的一段时间。但是由于数据库管理员可能在忙于其他的事情，没有注意到这方面的内容。久而久之，当故障发生后，才发现因为这些故障而导致原来针对这些灾难的安全措施都不起作用了。所以说，数据库管理员必须实时的了解这些安全措施的运行情况。但是数据库管理员毕竟精力有限，没有这么多的时间来跟踪这方面的内容。
为此笔者建议，作为数据库管理员最好能够自己开发或者直接采用数据库系统中的一些功能性脚本。这些脚本主要用来自动检测数据库的运行状况。如果数据库运行有问题，如在差异备份过程中有错误，则这些功能性脚本就会探测到这个问题，并通过邮件或者其他方式来告知数据库管理员，让他们能够及时的采取措施来解决这个问题。简单的说，这些基本功能脚本就是为数据库管理员提供了一种自动检测数据库的机制，可以用来炎症数据库是否可以回到可工作状态，以确认所有的作业都是在按预想的方式进行。
通常情况下笔者认为可能需要对如下的一些作业进行监控，以确保他们时刻都是有效的。一是数据库的备份策略，需要确保数据库在规定的时间内完成特定的备份(如差异备份与完全备份等等)。二是需要考虑某些触发器是否有效。有些触发器主要用来完成一些约束或者级联更新的功能。数据库管理员需要确保这些触发器是时刻有效的，不然的话很可能导致数据库中数据一致性的破坏。如果由于触发器无效导致级联更新的失败，这也是一种灾难。而且由于这个灾难比较难以发现，为此其危害度可能比服务器故障还要严重的多。所以说，需要通过基本功能脚本来自动检测这些触发器的有效性。
在上一篇《如何了解触发器的执行信息》文章中，笔者也介绍了一些查询触发器执行情况的手段。各位数据库管理员可以参看这篇文章的一些建议，来追踪触发器的执行情况。但是手工监督的话，工作量比较大，而且时间相隔也会比较久。为此比较理想的情况是，数据库管理员能够设计并运行一些基本的功能脚本，用来监督这些触发器的执行与生效情况。
为此笔者认为通常情况下，数据库管理员最好能够在灾难恢复计划中部署一些基本功能脚本，以确认所有事情都是在按管理员的预期方式运行。通过这些脚本，可以帮助数据库管理员来监督与检测数据库的运行情况，而不用等到用户来反映问题。