待解决
如同我们在本系列的上篇部分所指出的那样，数据库管理员对于任何灾难恢复方案的成功实施都是关键的一环。
>数据库管理员的成功需要许多其他关键人员的协助。数据库管理员需要服务器管理员来安装和设置好服务器；需要系统管理员来安装和设置好操作系统；需要存储管理员来复制好相应的磁盘；需要应用程序开发人员来帮助寻找出错误或故障的原因。数据库管理员甚至还依赖于其中的一些人员。
>许多步骤（如果不是全部的话）可以灾难发生前就完成或进行测试。在进行故障复原的时候，也可能某些领域会出现一些问题，并且必须重新设置这些领域。在正常时候，数据库管理员知道应该找谁以及同哪些人一起协同工作，但是如果灾难发生而且一些主要的支持人员不在，那么数据库管理员该如何应对呢？这些人可能在照顾受伤的家庭成员或自己也受了伤。那么如果你的数据库管理员也不在了呢？这些情境的发生概率必须予以适当的考虑。
>当员工遇到问题的时候，他们必须知道正确的寻找对象。
>避免找不到相关人员的最好办法之一就是对员工进行交叉培训。如果一个员工知道两个以上的工作职能和内容，那么他就可以在发生灾难的时候扮演关键角色，因为他知道如何做好两个以上的任务。
>在《安全计划和灾难恢复》（McGraw-Hill）一书中，Eric Maiwald 和William Sieglein指出，一些人员可能无法出现在恢复现场，使得一些领域无人负责，因此交叉培训能够帮助避免这种情况。除非员工自己要求，否则交叉培训不应该使员工完全脱离他们自己的正常职业。通常来说，更好的做法是让员工学习新的技能，同时这个技能也符合他们目前所从事的工作。
>例如，Oracle数据库管理员可以交叉培训成一名SQL Server数据库管理员。他们已经熟悉了这两种数据库共同的概念、SQL（结构式查询语言）、结构和数据库管理的其他功能。他们所要做的只是学习新数据库软件的不同工具集。这样对于组织和员工来说都是一个双赢的选择。员工学习宝贵的新技能可以帮助他们提升自己的职业发展道路。组织则得到了一个拥有多技能的员工，以便能够在异常情况和危机情势下依赖这些员工。
>备份
>数据库的要求会影响相关的备份类型。如果一个数据库可能会有数小时的宕机时间，而且在这种时候管理人员可以通过在前一个晚上的预先备份来满足要求，那么完全备份是好的做法。如果一点点的宕机时间和少量的数据损失是可以接受的，那么完全备份则没有很大的必要。
>像远程镜像这样的技术也有必要研究和考虑。在远程镜像中，生产系统中的所有变化都被复制到灾难恢复站点。由于大部分灾难恢复站点离主站有一定的距离，因此远程镜像一般异步进行。当需要故障复原的时候，数据库可以从被镜像的数据中予以恢复，以便保持业务的连续。
>另一个可以保持灾难恢复数据库更新的技术是数据复制。这种软件的基本功能是复制系统所发生的变化。这种功能可以进行调整为定期进行，比如每隔四小时进行一次。这样当用户发生错误操作的时候，就可以用于数据恢复。数据库管理员可以利用灾难恢复数据库来修正错误的生产数据。
>安装
>对于数据库管理员来说，数据库软件的安装是一个相当常规的任务，对于在不同的服务器中安装相同版本的数据库来说也是如此。数据库的安装和设置必须做好记录。当需要故障复原的时候，可能会发生无法找到数据库管理员的情况。清楚且详细、一步一步的安装及设置指导能够帮助其他领域的技术人员安装和设置数据库软件。
>话虽如此，但是每个生产服务器都是不同的。要准备好数据库可能需要做一些特定的事情。有些时候需要运行特定的脚本或者载入特定的任务或卸载一些数据。个别数据库的这些步骤以及这些数据的执行顺序必须详细清楚地予以记录。
>充分利用灾难恢复（DR）站点
>灾难恢复的最好办法就是建设专门的站点，在这些站点中安装同样的服务器和运行同样的应用程序软件，这样可以在需要的时候马上进行故障复原。但是这种方法的成本很高而且不普及。现实中还有一些其他实用的办法可以在实施灾难恢复站点的同时节省成本。
>双重利用灾难恢复设施的一个很好方法就是更新测试。所有的操作系统、应用程序和数据库都需要定期的维护补丁、修复和更新。由于灾难恢复设施的环境基本上和生产系统相同，因此这里是测试维护性发布主要地点。
>补丁和修复可以定期进入灾难恢复系统进行测试。在这个环境中，一个经过批准的测试系统可以检查维护性发布本身是否有问题。如果这些补丁本身没有发现任何问题，那么这些补丁可以根据计划定期迁移到测试环境。如果补丁在测试环境中也没有产生任何问题，那么这些补丁可以根据定期计划接着迁移到生产系统中去。
>如果这些维护性发布在灾难恢复站点或测试系统中发现了问题，那么这些补丁可以回滚到原来的状态。这样用户就可以不用再建立一个单独的实验性环境了。建立实验性环境的成本也可能比较高。用户不需要实验室所需的新的硬件、软件、许可证、维护、管理和空间就可以测试维护性发布。
>如果你目前还没有实验室来测试软件的补丁和修复，那么利用灾难恢复站点来测试维护性发布可以带来三种好处。首先，原来用于建立实验室的资金可以用于灾难恢复站点，而灾难恢复站点本身就是一个必须的设施。第二，你可以用一个基本上相同于生产系统的复制环境来测试软件的补丁，也就无需再建立实验室。第三，一旦这些补丁安装到生产系统中，管理人员就可以减少系统的维护。保持软件的补丁和修复可以减少系统的宕机时间以及管理人员用于系统修复的时间。
>对于数据库管理员来说，这种方式特别有好处。虽然在许多情况下，你可以用一个服务器来测试数据库的安装、补丁安装和更新，但是你很少能够用整个环境来测试所有这些任务。应用程序开发人员和用户希望能够在补丁已经被安装的情况下测试数据库的应用程序。数据库管理员可以进行有限的测试，但是用户在使用系统的时候才是真实的测试。
>在灾难恢复站点中部署试验服务器还可以让灾难恢复站点更快地启动和运行