待解决
大部分企业的最重要的信息都储存在数据库中。企业在计划使用新数据库应用软件时往往需要再三斟酌，加倍小心。 它们通常需要考虑存储器、服务器、高效率、容量和群集等因素。 在制定数据库的灾难恢复和业务连续性计划时，也必须采用相同的规划过程。任何涉及到企业尖端
>大部分企业的最重要的信息都储存在数据库中。企业在计划使用新数据库应用软件时往往需要再三斟酌，加倍小心。 它们通常需要考虑存储器、服务器、高效率、容量和群集等因素。
>在制定数据库的灾难恢复和业务连续性计划时，也必须采用相同的规划过程。任何涉及到企业尖端技术应用的行为都必须是有组织和审慎的。 中断是非常重要的事情，绝对不能掉以轻心。 正如2006年一篇关于财政规划的文章所述：“这不仅仅是将数据重现在电脑显示屏上，而是关乎业务是否能够继续进行下去。”如今，企业核心数据库往往会影响到服务中断时灾难恢复的正常进行。 业务部分中断或完全中断均会影响全局。规划业务持续性可以在必要时为重要业务提供容量。 业务持续性领域的资深专业人士明白，灾难过后业务仍可以继续。在制定某些规划时，必须弄明白如何让业务顺利进行下去。 灾难同时也会造成资产的损失。保险虽然可以弥补财务上的损失，但是却无法在一夜之间重建业务。 这就给员工带来了巨大的麻烦。这给员工和客户都造成了巨大压力。 如果没有合适的灾难恢复计划，就没有可能重建业务。
>必要条件
>首先要满足所支持的各数据库的必要条件。恢复时间可能是其中最重要的一个条件。 中断几秒钟与中断几分钟之间的区别可能会很大。有些业务的允许中断时间可能会达到几个小时。
>Charlene O’Hanlon在2007年的THE Journal文章中说：“你必须优先考虑你最需要的功能，你必须弄清楚什么是最重要的。”
>此外，还需考虑数据损耗的因素。如果无需考虑数据损耗的因素，那么在选择灾难恢复解决方案时只需考虑预算的问题。 如果昨晚的备份能够满足要求，那么这就可以节省大量的成本。
>制定灾难恢复解决方案时必须考虑容量的问题。应向客户咨询性能降低以及可接受的范围等事宜。 这是个很难回答的问题，必须在客户的帮助下才能找出答案。如果让它们自己来回答，它们一定会说性能完全不降低才行。
>在性能降低的同时，还需搞清楚在中断时访问系统的用户数量。这两个因素有助于确定更准确的容量需求。 必须说明的是，在中断期间，企业员工均不能使用企业应用软件。也许只有高级用户才需要运行功能强大的系统。
>人力资源应用软件就是个很好的例子。业务正常进行时，员工们需要使用人力资源应用软件来查工资、升级W-2等。 业务中断时，应禁止一般用户使用那些应用软件，但是高级用户仍可以使用工资系统、雇佣和解雇员工等等。只要数据库彼此之间无需互通，很可能你所需的容量没有你想象得那么多。 虚拟服务器也可以使用。 据Andreas Antonopoulos编写的一份Nemertes研究报告称：“你可能要频繁地例示虚拟机。因此，那些允许性能微降的企业就可以以更低廉的成本建立一个辅助数据中心来处理临时中断事故。”
>访问数据库和应用软件是另一个重要问题。如果主要的办公地点不能用，员工们就需要另一个地方来办公。 工作站需要配备必要软件来连接数据库。切记不可忽视这个要点。
>测试也非常重要。确定你测试灾难恢复计划的频率。 只有通过测试才能发现和解决问题。测试还可以改善灾难恢复计划。
>由于业务时常在变，你将在灾难恢复计划中发现同样的性能。要想保持灾难恢复计划的相关性和时效性，就必须经常进行测试。 测试的频率可以是一年一次，一年两次或者一季度一次。
>通常，灾难恢复的计划中不包括突发事件。突发事件只有在计划实施时才会发生。在制定数据库的灾难恢复计划时必须考虑到时间的因素。然而不幸的是，在其他计划面前，灾难恢复计划总是靠边站。将灾难恢复计划融入所有计划之中，那样才能及时完成灾难恢复计划。
>灾难恢复通常必须在短时间内完成。 除非万不得已，没人愿意总是呆在灾难恢复中心。 计划好中断时间、迁移、测试、决策和撤退过程。应将所有事务都计划好，用户必须彻底弄清损耗和转换计划。
>企业中必须有一个决策者来判定灾难的发生。确定这个决策者是谁以及应在灾难发生时传达出何种信息。 信息应通过多种形式发布。在灾难发生时，很少会出现各种通信方式都可以使用的情况。