数据库管理员应如何规划灾难恢复

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

在制定数据库的灾难恢复和业务连续性计划时，也必须采用相同的规划过程。任何涉及到企业尖端技术应用的行为都必须是有组织和审慎的。 中断是非常重要的事情，绝对不能掉以轻心。 正如2006年一篇关于财政规划的文章所述：“这不仅仅是将数据重现在电脑显示屏上，而是关乎业务是否能够继续进行下去。”如今，企业核心数据库往往会影响到服务中断时灾难恢复的正常进行。 业务部分中断或完全中断均会影响全局。规划业务持续性可以在必要时为重要业务提供容量。 业务持续性领域的资深专业人士明白，灾难过后业务仍可以继续。在制定某些规划时，必须弄明白如何让业务顺利进行下去。 灾难同时也会造成资产的损失。保险虽然可以弥补财务上的损失，但是却无法在一夜之间重建业务。 这就给员工带来了巨大的麻烦。这给员工和客户都造成了巨大压力。 如果没有合适的灾难恢复计划，就没有可能重建业务。

必要条件

首先要满足所支持的各数据库的必要条件。恢复时间可能是其中最重要的一个条件。 中断几秒钟与中断几分钟之间的区别可能会很大。有些业务的允许中断时间可能会达到几个小时。

Charlene O'Hanlon在2007年的THE Journal文章中说：“你必须优先考虑你最需要的功能，你必须弄清楚什么是最重要的。”

此外，还需考虑数据损耗的因素。如果无需考虑数据损耗的因素，那么在选择灾难恢复解决方案时只需考虑预算的问题。 如果昨晚的备份能够满足要求，那么这就可以节省大量的成本。

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

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

人力资源应用软件就是个很好的例子。业务正常进行时，员工们需要使用人力资源应用软件来查工资、升级W-2等。 业务中断时，应禁止一般用户使用那些应用软件，但是高级用户仍可以使用工资系统、雇佣和解雇员工等等。只要数据库彼此之间无需互通，很可能你所需的容量没有你想象得那么多。 虚拟服务器也可以使用。 据Andreas Antonopoulos编写的一份Nemertes研究报告称：“你可能要频繁地例示虚拟机。因此，那些允许性能微降的企业就可以以更低廉的成本建立一个辅助数据中心来处理临时中断事故。”

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

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

由于业务时常在变，你将在灾难恢复计划中发现同样的性能。要想保持灾难恢复计划的相关性和时效性，就必须经常进行测试。 测试的频率可以是一年一次，一年两次或者一季度一次。

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

灾难恢复通常必须在短时间内完成。 除非万不得已，没人愿意总是呆在灾难恢复中心。 计划好中断时间、迁移、测试、决策和撤退过程。应将所有事务都计划好，用户必须彻底弄清损耗和转换计划。

企业中必须有一个决策者来判定灾难的发生。确定这个决策者是谁以及应在灾难发生时传达出何种信息。 信息应通过多种形式发布。在灾难发生时，很少会出现各种通信方式都可以使用的情况。

如同我们在本系列的上篇部分所指出的那样，数据库管理员对于任何灾难恢复方案的成功实施都是关键的一环。

数据库管理员的成功需要许多其他关键人员的协助。数据库管理员需要服务器管理员来安装和设置好服务器；需要系统管理员来安装和设置好操作系统；需要存储管理员来复制好相应的磁盘；需要应用程序开发人员来帮助寻找出错误或故障的原因。数据库管理员甚至还依赖于其中的一些人员。

许多步骤（如果不是全部的话）可以灾难发生前就完成或进行测试。在进行故障复原的时候，也可能某些领域会出现一些问题，并且必须重新设置这些领域。在正常时候，数据库管理员知道应该找谁以及同哪些人一起协同工作，但是如果灾难发生而且一些主要的支持人员不在，那么数据库管理员该如何应对呢？这些人可能在照顾受伤的家庭成员或自己也受了伤。那么如果你的数据库管理员也不在了呢？这些情境的发生概率必须予以适当的考虑。

当员工遇到问题的时候，他们必须知道正确的寻找对象。

避免找不到相关人员的最好办法之一就是对员工进行交叉培训。如果一个员工知道两个以上的工作职能和内容，那么他就可以在发生灾难的时候扮演关键角色，因为他知道如何做好两个以上的任务。

在《安全计划和灾难恢复》（McGraw-Hill）一书中，Eric Maiwald 和William Sieglein指出，一些人员可能无法出现在恢复现场，使得一些领域无人负责，因此交叉培训能够帮助避免这种情况。除非员工自己要求，否则交叉培训不应该使员工完全脱离他们自己的正常职业。通常来说，更好的做法是让员工学习新的技能，同时这个技能也符合他们目前所从事的工作。

例如，Oracle数据库管理员可以交叉培训成一名SQL Server数据库管理员。他们已经熟悉了这两种数据库共同的概念、SQL（结构式查询语言）、结构和数据库管理的其他功能。他们所要做的只是学习新数据库软件的不同工具集。这样对于组织和员工来说都是一个双赢的选择。员工学习宝贵的新技能可以帮助他们提升自己的职业发展道路。组织则得到了一个拥有多技能的员工，以便能够在异常情况和危机情势下依赖这些员工。

备份

数据库的要求会影响相关的备份类型。如果一个数据库可能会有数小时的宕机时间，而且在这种时候管理人员可以通过在前一个晚上的预先备份来满足要求，那么完全备份是好的做法。如果一点点的宕机时间和少量的数据损失是可以接受的，那么完全备份则没有很大的必要。

像远程镜像这样的技术也有必要研究和考虑。在远程镜像中，生产系统中的所有变化都被复制到灾难恢复站点。由于大部分灾难恢复站点离主站有一定的距离，因此远程镜像一般异步进行。当需要故障复原的时候，数据库可以从被镜像的数据中予以恢复，以便保持业务的连续。

另一个可以保持灾难恢复数据库更新的技术是数据复制。这种软件的基本功能是复制系统所发生的变化。这种功能可以进行调整为定期进行，比如每隔四小时进行一次。这样当用户发生错误操作的时候，就可以用于数据恢复。数据库管理员可以利用灾难恢复数据库来修正错误的生产数据。

安装

对于数据库管理员来说，数据库软件的安装是一个相当常规的任务，对于在不同的服务器中安装相同版本的数据库来说也是如此。数据库的安装和设置必须做好记录。当需要故障复原的时候，可能会发生无法找到数据库管理员的情况。清楚且详细、一步一步的安装及设置指导能够帮助其他领域的技术人员安装和设置数据库软件。

话虽如此，但是每个生产服务器都是不同的。要准备好数据库可能需要做一些特定的事情。有些时候需要运行特定的脚本或者载入特定的任务或卸载一些数据。个别数据库的这些步骤以及这些数据的执行顺序必须详细清楚地予以记录。

充分利用灾难恢复（DR）站点

灾难恢复的最好办法就是建设专门的站点，在这些站点中安装同样的服务器和运行同样的应用程序软件，这样可以在需要的时候马上进行故障复原。但是这种方法的成本很高而且不普及。现实中还有一些其他实用的办法可以在实施灾难恢复站点的同时节省成本。

双重利用灾难恢复设施的一个很好方法就是更新测试。所有的操作系统、应用程序和数据库都需要定期的维护补丁、修复和更新。由于灾难恢复设施的环境基本上和生产系统相同，因此这里是测试维护性发布主要地点。

补丁和修复可以定期进入灾难恢复系统进行测试。在这个环境中，一个经过批准的测试系统可以检查维护性发布本身是否有问题。如果这些补丁本身没有发现任何问题，那么这些补丁可以根据计划定期迁移到测试环境。如果补丁在测试环境中也没有产生任何问题，那么这些补丁可以根据定期计划接着迁移到生产系统中去。

如果这些维护性发布在灾难恢复站点或测试系统中发现了问题，那么这些补丁可以回滚到原来的状态。这样用户就可以不用再建立一个单独的实验性环境了。建立实验性环境的成本也可能比较高。用户不需要实验室所需的新的硬件、软件、许可证、维护、管理和空间就可以测试维护性发布。

如果你目前还没有实验室来测试软件的补丁和修复，那么利用灾难恢复站点来测试维护性发布可以带来三种好处。首先，原来用于建立实验室的资金可以用于灾难恢复站点，而灾难恢复站点本身就是一个必须的设施。第二，你可以用一个基本上相同于生产系统的复制环境来测试软件的补丁，也就无需再建立实验室。第三，一旦这些补丁安装到生产系统中，管理人员就可以减少系统的维护。保持软件的补丁和修复可以减少系统的宕机时间以及管理人员用于系统修复的时间。

对于数据库管理员来说，这种方式特别有好处。虽然在许多情况下，你可以用一个服务器来测试数据库的安装、补丁安装和更新，但是你很少能够用整个环境来测试所有这些任务。应用程序开发人员和用户希望能够在补丁已经被安装的情况下测试数据库的应用程序。数据库管理员可以进行有限的测试，但是用户在使用系统的时候才是真实的测试。

在灾难恢复站点中部署试验服务器还可以让灾难恢复站点更快地启动和运行，并最大化这些服务器本身的使用价值。大部分情况下，数据中心购买这些测试服务器来测试新的项目，然后再让这些项目进入生产系统。测试服务器必须拥有和生产系统相同的规格或者更好的规格。大部分测试服务器需要更高的容量和功能，因为比起生产硬件，测试服务器通常需要运行更多的数据库、应用程序服务器、Web服务器。通过灾难恢复设施中的测试服务器，软件的许多安装工作实际已经完成。灾难恢复实例可以在测试服务器上建好，然后就可以让它们处于闲置状态，应用程序服务器、Web服务器和数据库只要等待需要故障复原的那一天就可以了。

使用虚拟化服务器也可以帮助灾难恢复站点降低成本，特别是在当前虚拟化技术的成本正变得越来越低且虚拟化技术的复杂性越来越低的时候。现在，虚拟服务器的实施要比过去容易得多。如今，市场上有许多应用程序、操作系统和数据库支持服务器虚拟化软件。这种情况的发生是因为虚拟化厂商正试图在他们之间建立更密切的协作，而且他们也同其他的软件厂商进行了良好和充分的合作。

来自客户的压力也促使软件公司同虚拟化公司合作以便认证和支持它们的虚拟化产品。通过虚拟化，一个物理服务器可以被镜像并在虚拟环境中产生一个虚拟服务器。一个包含Web服务器、应用程序服务器和数据服务器的生产系统可以被全部镜像并在一个物理服务器上进行虚拟化。这种方式能有效地将三个物理服务器合并成一个服务器，同时还保留了所有的功能。虽然虚拟化后的容量可能不一样，但是对于灾难恢复来说也足够用了。这种方式并不意味着所有的应用程序都必须在虚拟服务器上工作，它们必须能够共同存在。

导师

交叉培训之外的一个关键步骤是导师计划。通过导师计划，一个对不同领域感兴趣并希望成为该领域专家的员工可以同项目专家直接沟通。对于雇主来说，这种制度还可以提升员工士气，从而为企业带来回报。对于员工来说，当他们希望通过交叉培训得到另一个技术团队的空缺职位时，导师计划也可以在这方面帮助这些员工。

通过为员工打开不同团队之间的职业空间和机会，个人员工将备受鼓舞，他们将感觉到自己不会局限于自己目前所从事的工作。例如，一个数据库管理员的职位可能很难从外部招聘。而一个拥有相应的才能、能力并且希望成为数据库管理员的开发人员可能因为缺少相关的经验却错失这个机会。通过导师计划这种方式，个人员工可以在工作变动上得到帮助，同时符合条件的候选人员也可以得到新的职业路径。

导师计划可以在团队内部以及不同团队之间传播知识和技能，当项目专家无法抵达现场或失去工作能力的时候，导师计划可以为灾难恢复提供支持性人员。通过在导师计划中记录下过程和流程，组织和系统应对故障或灾难并采取响应行动的能力将大大提升。

作者Kevin Medlin自1997年以来曾经在多个行业（包括能源、零售、保险和服务）中担任过管理、支持和开发职位。他目前是一位DBA（数据库管理员），熟悉Oracle和SQL Server数据库，而且通过了Oracle版本8到10的技能认证。他在Regis大学获得存储局域网毕业证书，并将在2008年获得东卡来罗那州立大学的技术系统硕士学位。