数据库管理员如何制定灾难恢复和业务持续性计划

    大部分企业的最重要的信息都存储在数据库中。企业在计划使用新数据库应用软件时往往需要花费大量的时间和精力，再三斟酌。它们通常需要考虑存储器、服务器、高可用性、容量和集群等因素。

　　在制定数据库的灾难恢复和业务持续性计划时，也必须采用相同的规划过程。任何涉及到企业关键应用软件可用性的行为都必须是有组织的、慎重的。业务是非常严重的事情，绝对不能掉以轻心。正如2006年《金融规划杂志》中的一篇文章所述：“这不仅仅是在电脑显示屏上重现数据，而是关乎业务是否能够继续进行下去。”如今，企业核心数据库往往会影响到服务中断时灾难恢复的正常进行。

　　业务部分中断或完全中断所带来的影响都将是压倒性的。业务持续性计划可以在必要的时候为关键业务操作提供所需的容量。业务持续性领的资深专业人士明白，灾难过后业务仍可以继续。在制定某些规划时，必须弄明白如何让业务顺利进行下去。

　　此外，灾难造成的资产损失也是巨大的。保险虽然可以弥补财务上的损失，但是却无法在一夜之间重建业务。这需要工作人员大量的身心投入。同时这些灾难给员工及其客户都造成了巨大压力。如果没有合适的灾难恢复计划，就没有可能重建业务。

　　必要条件

　　首要之事就是要满足所支持的各种数据库的必要条件。恢复时间可能是其中最重要的一个条件。中断几秒钟与中断几分钟之间的区别可能会很大。有些业务单元允许的中断时间甚至可能会达到几个小时。为了有效的发挥灾难恢复计划的作用，你必须要知道每个数据库的恢复时间。Charlene O'Hanlon在2007年的THE Journal文章中写道：“你必须要优先考虑你最需要的功能，必须弄清楚究竟什么才是最重要的。”

　　另一个需要考虑的重要因素是数据丢失。如果任何少量的数据丢失都不允许存在，那么在选择灾难恢复解决方案时就需要重点考虑预算问题。如果昨晚的备份能够满足要求，那么这就可以节省大量的成本。

　　制定灾难恢复解决方案时必须要考虑容量问题。应向客户咨询有关性能降低以及可接受的范围等事宜。这是个很难回答的问题，必须在客户的帮助下才能找出答案。如果让它们自己来回答，它们一定会说要性能完全不降低才行。

　　在性能降低的同时，还需搞清楚在中断时访问系统的用户数量。这两个因素有助于确定更准确的容量需求。必须说明的是，在中断期间，企业员工均无法使用企业应用软件。也许只有高级用户才需要运行功能强大的系统。

　　人力资源应用软件就是个很好的例子。业务正常进行时，员工们需要使用人力资源应用软件来查工资、升级W-2等。业务中断时，应禁止一般用户使用那些应用软件，但是高级用户仍可以使用工资系统、雇佣和解雇员工等等。只要数据库彼此之间无需互通，很可能你所需的容量就没有你想象得那么多，也即同样的服务器上允许存在更多的数据库。此外，虚拟服务器也可以使用。

　　据Andreas Antonopoulos编写的一份Nemertes研究报告称：“你可能要频繁地来举例说明虚拟机的虚拟至物理映射过程。结果，那些允许性能微降的企业就可以以更低廉的成本建立一个辅助数据中心来处理临时中断事故。”

　　访问数据库和应用软件是另一个重要问题。如果主要的办公地点不能用，员工们就需要到另一个地方办公。工作站需要配备必要的软件来连接数据库。切记不可忽视这个要点。

　　测试非常重要。确定你测试灾难恢复计划的频率。只有通过测试才能发现和解决问题。测试还可以改善灾难恢复计划。

　　业务时时在变，灾难恢复计划同样如此。要想保持灾难恢复计划的相关性和时效性，就必须经常进行测试。测试的频率可以是一年一次，一年两次或者一季度一次。灾难恢复计划和灾难恢复解决方案更接近实际经历，就越有利于从危机状况中恢复。熟练掌握灾难恢复计划可以提高自信心，以及增强对设备和系统的信赖。

　　通常，灾难恢复的计划中不包括突发事件。突发事件只有在计划实施时才会发生。在制定数据库的灾难恢复计划时必须考虑到时间因素。然而不幸的是，在其他计划面前，灾难恢复计划总是靠边站。将灾难恢复计划融入到所有计划之中，那样才能及时完成灾难恢复计划。

　　重新回到主站点将是一件令人兴奋的事。这个过程同时也将是忙乱的，因为灾难恢复通常必须在短时间内完成。 除非万不得已，没人愿意总是呆在灾难恢复中心。计划好中断时间、迁移、测试、决策和撤退的全过程。应将所有事情都计划好，用户必须彻底弄清损耗和转换计划。

　　企业中必须有一个决策者来判定灾难的发生以及应该采取失效备援。确定这个决策者是谁以及在灾难发生时如何进行信息的沟通传递。理想情况是，信息应通过多种形式发布。在灾难发生时，很少会出现各种通信方式都可以使用的情况。