数据库管理员的灾难恢复和业务持续性计划之二

copyking

   有很多重要的角色对数据库管理员成功起着关键作用。服务器管理员需要安装和设置服务器。系统管理员需要安装和启动
操作系统
。存储管理员需要复制相应的磁盘。应用开发人员需要协助解决用户检测到的错误。这些都是数据库管理员将要依赖的对象。
　　以上这些操作中有很多(甚至全部)都可以在灾难和考验到来之前完成。当故障发生时，如果这些领
域
中某些方面需要重新审查，就会存在问题。虽然在正常的情况下，数据库管理员可能知道该如何寻找帮助，但是，当灾难袭击且某些关键的人力支持缺乏时，该怎么办?他们可以照顾受伤的家庭成员或者是自己。如果数据库管理员不在怎么办?伴随着这些情景的种种意外情况的处理都应该付诸实施。
　　当务之急，员工们要知道当他们碰到问题时应该向谁寻求帮助。
　　避免这种情形发生的最佳方法之一就是交叉训练员工。对于员工来说，多掌握一门工作技能是非常有必要的，可以在灾难
中断
期间扮演着一个重要的角色，因为他所知道的不仅只局限于某个领域或某项工作职能。
　　正如有专家指出：“有些人可能无法成功恢复站点，并保持其它领域不受影响。”交叉培训并不要求员工完全地从其正常的职业岗位中转移，除非员工自己主动要求。让员工多掌握一门与其目前所从事的职业相关的新技能，这通常会更有效。
　　例如，Oracle数据库管理员可以按照SQL
Server
数据库管理员的要求进行交叉培训。他们对数据库管理的相关概念、SQL、结构和其它功能都已经很熟悉。这种培训基本上应该就是学习新的不同的数据库软件工具。对于员工和组织来说，这是一项双赢的举措。
　　从员工的角度来看，其掌握了宝贵的新技能，这样可以强化他们的职业生涯。对于组织来说，其雇员获得了多种不同的技能，可以更好地应对各种正常状态及危机状况。
　　备份
　　数据库的需求决定了备份的类型。如果数据库可以容许几小时的宕机时间，并且昨晚的备份足以支持工作的开展，那么使用一个完整备份就可以。如果数据库允许的宕机时间很少或几乎不允许，或者是很少或几乎不允许有数据丢失，那么完整备份就无法满足这个需求了。
　　我们可以对各种技术进行调研，如远程镜像。在远程镜像中，生产系统发生的所有变化都被复制到灾难恢复站点。通常，这被当作是一种异步数据，因为大多数的灾难恢复站点离主站点都有一定的距离。当故障发生时，数据库可以从镜像数据中恢复，从而保持业务的连续性。
　　数据复制是另一项技术，它可以保持灾难恢复数据库的更新。在生产数据库到灾难恢复站点数据库之间进行复制，软件复制的本地设置就会发生变化。这种设置也可以改变，可以设置其按照特定的时间规律变化，例如每4个小时变化一次。万一用户操作失误，这就作为一个数据恢复情景。数据库管理员可以使用灾难恢复数据库的数据来纠正生产的错误，因为生产中的变化已经被推迟。
　　安装
　　对于数据库管理员来说，数据库软件的安装应该是一项常规任务。只要数据库版本相同，在不同的服务器之间安装数据库软件也应该是一样的。安装和设置的过程应该归档。当发生故障时，数据库管理员不在，这种情况经常有可能会出现。简要来看，在数据库管理员不在的情况下，一步一步的安装向导将使其它领域的专业技术人员具备相应的能力来接管相关的工作，并安装数据库软件。
　　这也就是说，每个生产服务器都是不同的。某些服务器可能需要准备好数据库。有些时候需要运行特定的脚本程序或任务来加载或卸载数据。每个数据库的这些步骤及其执行顺序都应该进行严格归档。
　　有效利用灾难恢复站点
　　创建灾难恢复站点的最佳方法是通过建立一个专用站点，保持其服务器的有效性和应用软件的正常运行，这样，当故障发生需要调用灾难恢复时，可以立即响应需求。这种做法的成本也非常高，而且并不总是受欢迎。但是，这种方法还具有执行灾难恢复站点的作用，能够节约成本，而且实用。
　　这种设备还具备双重用途，它是升级测试的一个很好的方法。所有的操作系统、应用软件和数据库都需要经常维护补丁、修补和升级。使用有效环境作为生产系统的精确复制，这是测试评估版软件的“黄金场所”。
根据正常计划表，补丁和修补适用于灾难恢复系统。一项经批准的测试计划可以用于管理环境，以检测出评估版软件中存在的问题。如果没有发现问题，就可以将这个补丁放在合适的地方，然后按照正常计划日程将其移植到测试环境。如果还没有发现问题，就可以按照计划将这些补丁移植到生产环境。
　　只要在灾难恢复站点或测试系统中发现问题，那么这个补丁就要被打回，或者如果厂商的问题无关紧要，可以向其指出并要求其改正。这样就不需要单独的实验室环境，从而节约昂贵的成本。无需额外的硬件、软件、许可证、维护、管理或空间场所来对评估版软件进行测试。
　　如果目前你还有没有一个试验室来测试软件的补丁和修补，那么这将从3个方面为你带来大量的好处。首先，你已经在灾难恢复站点上投入了资金，这种投入本身就是有必要的。其次，现存的生产系统的复制环境用于测试软件补丁，这就不需要实验室。第三，一旦打上补丁，系统上所需的管理维护就会越来越少。保持软件的补丁实时更新能够降低宕机时间，减少管理员在系统维护上的时间投入。
　　对于数据库管理员来说，这种方法特别重要。虽然很多时候，服务器的安装、补丁和升级都是可用的，但是很少有完整的环境来执行这些任务。应用程序开发商和用户需要的就是在补丁安装之后对数据库进行测试。虽然数据库管理员可以执行某些受限制的测试，但是只有当用户将系统投入运转时，才算是真正的测试。
　　在测试服务器上存储灾难恢复站点的测试服务器是使灾难恢复站点启动和快速运行的另一种有效的方法，可以使服务器的价值达到最大化。在大多数情况下，这些服务器都是为某一个新项目采购的，该项目将被移植到生产环境。测试服务器应该按照相同的规格购买，或是比生产的更好。大部分测试服务器需要更高的容量，因为其上运行的数据库、应用服务器、Web服务器及类似的程序要比生产服务器多。在灾难恢复设施中使用测试服务器，大部分的软件安装工作都已经完成。可以在测试服务器上创建灾难恢复实例，并使其处于空闲状态。应用程序服务器、Web服务器和数据库只是等待故障警报响起的那一天。
　　使用虚拟服务器可以帮助降低灾难恢复站点的成本，特别是在这项技术的成本越来越低，操作越来越简单的情况下。现在实施虚拟服务器要比过去容易得多。如今，许多应用软件，操作系统和数据库都支持服务器虚拟化软件。自从很多虚拟化厂商试图密切、充分地与其他软件供应商展开合作之后，这种情况就已经发生改变了。
　　来自客户的压力也推动了软件公司与虚拟化企业的合作，以认证和支持他们的产品。通过虚拟化技术，一台物理服务器可以被映像，并复制到虚拟环境中。一个由Web服务器，应用服务器和数据库服务器组成的生产系统可以进行映像并且虚拟一个单一的物理服务器。这有效地将三个物理服务器缩减到一个，而不会丢失任何功能。虽然容量可能是相同的，但是这可能足以应对灾难恢复情景。这并不意味着所有应用程序会在虚拟服务器上一起运行，但是它们必须能够共存。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/66684/showart_1684732.html