如同我们在本系列的上篇部分所指出的那样，数据库管理员对于任何灾难恢复方案的成功实施都是关键的一环。
数据库管理员的成功需要许多其他关键人员的协助。数据库管理员需要服务器管理员来安装和设置好服务器；需要系统管理员来安装和设置好操作系统；需要存储管理员来复制好相应的磁盘；需要应用程序开发人员来帮助寻找出错误或故障的原因。数据库管理员甚至还依赖于其中的一些人员。
许多步骤（如果不是全部的话）可以灾难发生前就完成或进行测试。在进行故障复原的时候，也可能某些领域会出现一些问题，并且必须重新设置这些领域。在正常时候，数据库管理员知道应该找谁以及同哪些人一起协同工作，但是如果灾难发生而且一些主要的支持人员不在，那么数据库管理员该如何应对呢？这些人可能在照顾受伤的家庭成员或自己也受了伤。那么如果你的数据库管理员也不在了呢？这些情境的发生概率必须予以适当的考虑。
当员工遇到问题的时候，他们必须知道正确的寻找对象。
避免找不到相关人员的最好办法之一就是对员工进行交叉培训。如果一个员工知道两个以上的工作职能和内容，那么他就可以在发生灾难的时候扮演关键角色，因为他知道如何做好两个以上的任务。
在《安全计划和灾难恢复》（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年获得东卡来罗那州立大学的技术系统硕士学位。
