IBM的数据库容灾解决方案

shujuhuifu802

                第一章 企业面临的挑战以及发展趋势
1.1前言
1958年，Bill Gore 和他的太太 Vieve Gore在美国特拉华州Newark市，自己家里的地下室成立了Gore公司。1969年，Gore公司研制成功独特的，具有防风、防水、透气功能的GORE-TEX面料并广泛应用于生产具有功能性、保护性和时尚感的服装和鞋类产品。目前，Gore公司已成为一家在全球拥有6000多名员工、40多间加工厂的跨国公司，并在氟材料的技术研究和应用领域始终占据世界领先地位。
对于Gore这样的以研发新型材料作为企业动力的公司而言，材料的研发过程记录、研发历史数据、研发结果数据是企业最可宝贵的财富。请假设这样一种情况，如果这些数据在一次事故中全部丢失，Gore公司会蒙受多么大的损失？
1983年，当个人电脑还处于萌芽期的时候，美国青年戴尔成立了自己的个人电脑公司，主要销售IBM的旧电脑和自己组装的品牌电脑。那是一个电脑群雄激烈厮杀的年代，当行业的领导者们争相以引人注目的技术推出计算机时，戴尔注意到了平凡的供应链。戴尔公司利用信息技术全面管理公司生产过程。通过互联网，戴尔公司和其上游的配件制造商能够对客户的定单迅速地做出反应：当定单传至戴尔的控制中心时，控制中心把定单分解为一个个子任务，并通过网络分派给各独立配件制造商进行生产。各制造商按照戴尔的电子定单进行生产组装，并按照戴尔控制中心的时间表来供货。戴尔所需要做的只是在成品车间完成组装和系统测试，剩下的就是客户服务中心的事情了。“经过优化后，戴尔供应链每20秒钟汇集一次定单”，“平均库存时间仅有7小时”。虽然没有傲视群雄的杰出技术，现在的戴尔公司却已成长为一个年销售额达410亿美金的企业。
对戴尔公司来说，市场信息的获取、物流信息的传递以及合作伙伴的信息交换，这些共同构成了拉动企业正常运转的信息链。如果有一天，一场意外的事故导致供应链的崩裂，戴尔该如何面对客户恼怒的面容和企业直线下滑的利润？
信息，作为企业宝贵的资源，其重要性已经得到了人们的充分认识。但是我们该如何保护这一资源？假设您就是某企业的一位高级管理人员，当您的企业遭遇以下事故时，您将如何去面对：
1． 某一天，证券公司的交易数据因操作失误而损坏；
2． 某一天，保险公司的所有保单数据因电源故障而丢失；
3． 石油勘探公司辛苦一年获取的地质数据因人为的恶意操作而丢失；
4． 医院保存的所有病历因为磁带的损坏而无法使用；
……
这样的例子还有很多很多。
那么这样的事故所带来的后果是什么？至少，很难想象这个不幸的企业还能毫发无损的健康生存。因为，对于信息时代的企业而言，健全的信息往往是维持其运转所必须的基本条件。所以，如何保护企业的信息资源，如何使企业免遭信息灾难，已经成为企业所必须考虑的沉重问题。

第二章 容灾概述


2.1 概述
常言道，“知己知彼，百战不殆”。要实现容灾，首先要了解我们的“敌人”－ 灾难。
那么，哪些事件可以定义为灾难呢？典型的灾难事件是自然灾难，如火灾、洪水、地震、飓风、龙卷风、台风等，还有其它如原先提供给业务运营所需的服务中断，如设备故障、软件错误、电信网络中断和电力故障等等。此外，人为的因素往往也会酿成大祸，如操作员错误、破坏、植入有害代码和恐怖袭击。现阶段，由于我国很多行业正处在高速发展的阶段，很多生产流程和制度仍不完善，加之缺乏经验，这方面的损失屡见不鲜。事实上，我国2003年遭遇的“非典”，某种意义上也是灾难。对此，我们认为需要做到两点：一是建立切实可行的应急机制，这主要包含一套基于充分且清楚地将风险予以分类定义的业务持续计划，二是在危机突然降临时，此计划能被有效执行。
对于IT系统，除了上述的灾难之外，与系统相关的计划外宕机也可视作灾难（见图1）。

图1.停机原因分析－北美
自“9.11”之后，全球各企业均认识到灾难防范保护的重要性。某些大型金融机构之所以能够在两天内恢复营业，其主要原因是它们不仅象一般公司那样在内部进行数据备份，而且在数英里外的数据备份中心也保留着数据备份。这些备份都是通过数据备份软件和数据复制软件进行的。采取了这种措施后，一旦工作现场发生意外，企业就可以立即使用另一套数据。华尔街的金融机构重新对灾难恢复的步骤做了评估，并认识到灾难恢复只是技术手段之一，它们开始强调 Business Continuity - 业务连续性而不仅仅是 Disaster Recovery - "灾难"恢复。因为过去的"灾难"恢复计划并没有强调全局性及对整个市场的影响，而如何维持业务的连续运作将成为企业运营风险评估中至关重要的一环。事实证明，只有对数据存储备份制定完备、持续且可执行的容灾计划，特别是业务连续计划，才能为人们提供万无一失的数据安全保护。
严格的说，容灾计划包括一系列应急计划，如业务持续计划(BCP-Business Continuity Plan)，业务恢复计划(ERP-Business Recovery Plan)，运行连续性计划(COOP-Continuity of Operations Plan)，事件响应计划(IRP-Incident Response Plan)，场所紧急计划(OEP-Occupant Emergency Plan)，危机通信计划(CCP-Crisis Communication Plan)，灾难恢复计划(DRP-Disaster Recovery Plan)等等。
业务持续计划(BCP)
它是一套用来降低组织的重要营运功能遭受未料的中断风险的作业程序，它可能是人工的或系统自动的。业务持续计划是高层管理人员的首要职责，因为他们被委任于保护公司的资产及公司的生存。业务持续计划的目的是使得一个组织及其信息系统在灾难事件发生时仍可以继续运作。为了能对灾难事件有适当的对策，严密的计划及相关资源的投入是必须的。
业务恢复计划(BRP)
它也叫业务继续计划，涉及紧急事件后对业务处理的恢复，但与BCP不同，它在整个紧急事件或中断过程中缺乏确保关键处理的连续性的规程。BRP的制定应该与灾难恢复计划及BCP进行协调。BRP应该附加在BCP之后。
操作连续性计划(COOP)
COOP 关注位于机构（通常是总部单位）备用站点的关键功能以及这些功能在恢复到正常操作状态之前最多30天的运行。由于COOP涉及到总部级的问题，它和BCP是互相独立制定和执行的。COOP的标准要素包括职权条款、连续性的顺序和关键记录和数据库。由于COOP强调机构在备用站点恢复运行中的能力，所以该计划通常不包括IT运行方面的内容。另外，它不涉及无需重新配置到备用站点的小型危害。但是COOP可以将BCP、BRP和灾难恢复计划作为附录。
危机通信计划(CCP)
机构应该在灾难之前做好其内部和外部通信规程的准备工作。危机通信计划通常由负责公共联络的机构制定。危机通信计划规程应该和所有其它计划协调，以确保只有受到批准的内容公之于众，它应该作为附录包含在BCP中。通信计划通常指定特定的人员作为在灾难反应中回答公众问题的唯一发言人。它还可以包括向个人和公众散发状态报告的规程，例如记者招待会的模板。
计划(IRP)
事件响应计划建立了处理针对机构的IT系统攻击的规程。这些规程用来协助安全人员对有害的计算机事件进行识别、消减并进行恢复，这些事件的例子包括：对系统或数据的非法访问、拒绝服务攻击、或对硬件、软件、数据的非法更改（如有害逻辑：病毒、蠕虫或木马等）。本计划可以包含在BCP的附录中。
灾难恢复计划 (DRP)
正如其名字所表示的，DRP应用于重大的、通常是灾难性的、造成长时间无法对正常设施进行访问的事件。通常，DRP指用于紧急事件后在备用站点恢复目标系统、应用或计算机设施运行的IT计划。DRP的范围可能与IT应急计划重叠，但是DRP的范围比较狭窄，它不涉及无需重新配置的小型危害。根据机构的需要，可能会有多个DRP附加在BCP之后。
场所紧急计划 (OEP)
OEP在可能对人员的安全健康、环境或财产构成威胁的事件发生时，为设施中的人员提供反应规程。 OEP在设施级别进行制定，与特定的地理位置和建筑结构有关。设施OEP可以附加在BCP之后，但是独立执行。
BCP关注在中断期间和之后维持机构的业务功能。业务功能的一个可能的例子是工资的支付处理或客户的信息处理。BCP可以专门为某个特定的业务处理编写也可以涉及到所有关键的业务处理。IT系统在BCP中被认为是对于业务处理的支持。在某些情况下，BCP可能没有涉及到对过程的长期恢复并使其回到正常运行状态，而只是包含过渡的业务连续性需求。灾难恢复计划、业务继续计划和场所紧急计划可以附加在BCP之后。在BCP中设定的职责和优先顺序应该和其在操作连续性计划（COOP）中的一致以消除可能的冲突。
按一般惯例，备用站点维持机构（通常是总部）要支持长达30天的运行，直到整个系统恢复到正常状态，COOP正是为了达到这个要求而制定的。BCP涉及到在重大中断期间和之后维持业务处理所需的业务功能和IT系统。BRP记录了机构在备用站点进行业务处理的持续规程。与BCP不同，BRP不涉及在紧急事件期间对关键处理的连续性维持。DRP是指设计用于重大和通常是毁灭性灾难之后的目标系统、应用程序或计算机设施的恢复，它是以IT为主的计划。两个计划都提供了IT系统的恢复和继续规程。由于包括了对无需重新部署到备用站点的小型中断进行系统恢复的规程，所以这类计划比DRP的范围更广泛。计算机事件响应计划建立了使安全人员可以确定、防止和恢复针对机构IT系统进行的计算机攻击的规程。OEP则提供了在人员的健康和安全以及环境或财产等受到威胁的紧急情况下，设施工作人员所遵循的指导方针。计划的制定者之间必须进行协调以确保各自的策略和规程能够互为补充，必须将所有有关计划、系统和处理的变化情况反馈给系统和相应处理计划的制定者。

第三章 容灾方案分析
在现代企业的IT系统管理过程中，常常会遇到各种有关灾难备份范畴的需求，例如：
  “无论发生任何问题，业务系统必须在最短的时间内恢复！       ”；
  “无论发生任何问题，数据绝对不能丢失！”
   ……
针对这些问题，有经验的管理人员可能会考虑到一系列由此引发的问题：
  “究竟有些什么因素可能导致业务中断？”
  “究竟最短的时间是多长？”
  “是否所有的应用系统数据都不能丢失？”
  “这些恢复目标是否合理？”
  “目前的IT架构是否能够满足所要求的恢复目标？”
  “是否IT系统得到恢复，就意味着业务部门可以对客户进行服务？”
  “如何衡量灾难备份方案的投入产出比？”
……
回答以上这些问题的过程，就是考虑企业业务连续性的过程。事实上，随着IT系统在企业内部应用的深入，灾难备份在企业中已不是IT一个部门的问题，而是整个企业各业务部门与IT部门紧密合作的问题。其内容也不仅局限于数据的备份和应用的接管，还包含了网络的冗余、人员与组织架构的整理、恢复流程的设计等一系列技术以外的范畴。目的在于保证在灾难环境下，企业真正从业务的角度得到保护，而不仅仅是IT环境的恢复。
3.1业务连续性开发模式
各行各业的用户，需要针对自身情况，设立可行的业务恢复目标，并制订出切合实际、投资合理、可靠的业务连续性及技术方案。这种业务连续性开发模式，体现在业务连续性或灾难备份的项目中，就是灾难备份项目实施的步骤：
1. 灾难类型分析
2. 业务冲击分析
3. 当前业务环境及恢复能力分析
4. 容灾策略制订
5. 容灾方案设计
6. 业务连续性流程设计
7. 业务连续性流程及容灾方案管理和测试
其过程如下图所示，是一个周而复始的过程，随着企业内部环境的变化随时灵活变化：

图一. 灾难备份项目实施过程
3.1.1阶段一、灾难类型分析（风险分析）
在本阶段，需要进行详细而量化的风险分析，以确定当前IT环境之中存在哪些无法接受的物理威胁或者可能发生的灾难，并对灾难发生的可能性、目前可能的防护措施的有效性和该灾难所威胁的资产价值进行分析，最终得到带有优先级别的需要防护的灾难列表，并制订可能的处理方法，如接受该灾难发生的风险而不进行防护、自行制订该灾难的防护方法或者采取购买保险等风险转嫁策略。其结果可以由下图表示：

在该图中，横坐标为风险发生的可能性，纵坐标为风险发生所造成的损失。在某一风险发生的可能性极小时，即使造成的损失极大，也可能属于可接受的风险范畴，例如美国的“9?11”事件。但该接受程度是与时俱进的，在“9?11”事件发生后，事实是大部分没有考虑这种大范围灾难性事件的企业基本没有得到恢复的机会。目前业界也已经将低概率事件逐渐纳入防护的范围。
3.1.2阶段二、业务冲击分析
在本阶段，应该针对各种业务流程进行分析，通过走访各业务部门的相关人员，了解各种业务流程本身对该企业的重要程度。（例如在银行业里，储蓄和单据、网上支付、电话银行等业务就具有不同的优先等级。）同时根据一定的评判原则，得出在核心流程由于灾难的发生而无法正常进行时对企业本身的损失情况。这种损失可能是可以量化的，例如单据的丢失、计算的错误而导致的直接损失；也可以是无形的损失，例如客户满意度及竞争优势的丢失。通过对可量化和不可量化损失的综合考虑，得出各种核心业务流程由于灾难受损的可容忍程度及损失的决策依据。体现在IT系统上，是三个指标：
   
   数据恢复点目标（RECOVERY POINT OBJECTIVE）：体现为该流程在灾难 发生后，恢复运转时数据丢失的可容忍程度；
   
   恢复时间目标（RECOVERY TIME OBJECTIE）：体现为该流程在灾难发生后，需要恢复的紧迫性也即多久能够得到恢复的问题；
   
   网络恢复目标（NETWORK RECOVERY OBJECTIVE）：即营业网点什么时候才能通过备份网络与数据中心重新恢复通信的指标；
对于不同的业务流程，这三个指标可能相差非常之大，各个流程本身对这三个目标的优先程度也是不一样的，有的流程可能要求数据丢失的程度较小，但恢复时间可以较长，而另一些流程可能要求短时间内恢复，但数据的丢失程度可以放大一些。这三个指标直接影响所使用的容灾策略及技术方案，并指导企业的投入成本。可以用下图表示：

图3. 业务冲击分析曲线
在该图中，横坐标为灾难持续时间，纵坐标为灾难损失，在某一程度以下属于可接受的程度，即横虚线所示。这种可接受决策应该由负责该流程的业务部门综合考虑后做出。
3.1.3阶段三、企业容灾环境分析
本阶段主要针对业务冲击分析的结果，对目前的内部环境进行评估，得出与恢复目标之间的差距。分析的对象为业务流程需要的资源，如IT环境等。通过本阶段的工作，得出各业务流程所牵涉的企业资产及资源（人力资源、IT架构、技术储备、技术使用程度、网络环境等），并分析得出目前的业务环境对容灾需求、冗余程度、可能造成的数据损失是否能够支持等方面的报告。用下图表示：

图4. 容灾环境分析
图中右边红线为目前环境所支持的容灾能力，左边红线为经过业务冲击分析所得到的需要达到的恢复能力，在灾难恢复时间和灾难造成损失两个方面都需要得到降低。
3.1.4阶段四、容灾策略制订
在本阶段，结合以上各阶段的分析成果，以及企业本身在容灾上的投入能力，制订企业短期、长期范围内的容灾策略和目标，并有意识地将企业本身的人员组成和组织架构做出调整以适应策略要求。最重要的是制订出容灾实施步骤，优先解决最为重点的问题。如下图所示：

图5. 容灾策略制订
3.1.5阶段五、容灾方案设计
容灾方案可供选择的范围很大，但所有的容灾方案都必须考虑的因素包括恢复时间、实施与维护容灾策略所需的投入等。容灾恢复时间的需求越短，所需的实施成本就越大，实施难度也就越高。恢复时间与投入的比值可以用以下这张曲线图加以说明：

图6. 容灾方案层次
图中的各种层次方案可以分别满足不同的数据恢复目标和恢复时间目标，需要根据业务冲击分析的结果，针对每一种业务流程，综合选择能够满足容灾目标的方案。
3.1.6 阶段六、业务连续性流程设计
有了IT系统的恢复方案，只能够保证在灾难环境下，IT系统的恢复能够保证业务冲击分析的目标，但是业务的连续性并不只是IT系统的恢复，还包括办公场地、办公设备、紧急流程、指挥架构、人员调度等等多方面、各部门的综合考虑。只有业务流程执行过程的每一个环节都达到容灾目标的要求，才能够认为业务冲击分析的目标得到了满足。一般来说，每个企业都应该设立一个由领导挂帅，各业务部门和IT部门联合组成的一个容灾指挥小组：


图7. 容灾组织架构图
由该小组指挥，IT部门和业务部门分别执行，IT恢复计划和业务连续性计划才能得到同步，从而达到容灾设计的目标。
3.1.7阶段七、业务连续性流程及容灾方案管理和测试
任何制订的计划，都必须经过不断的测试和修正，才能满足企业不断发展的需求。同时，通过测试过程，也能够使企业内部各部门及人员熟悉自己在业务连续性计划中所扮演的角色，做到胸有成竹，才能够在灾难真正发生的时刻有条不紊地开展恢复的过程。
测试的过程可以分为“纸上谈兵”和实地演习两种方式，根据企业需要及对业务影响的不同分别采用。
需要注意的是，无论平时的测试如何完善，也没有办法预测可能发生的灾难情况。关键人员的损失或者关键文档的丢失，都有可能对灾难恢复计划的执行造成巨大影响。因此，在灾难演练过程中要注意到人员的交叉备份情况，除了每个人自己所担负的责任外，尽量做到关键步骤有后备人选作为应变。


第四章 容灾系统的设计过程
容灾方案的制定是一个系统的过程，包含一系列的工作及计划的制订，包括Business Continuity Planning (BCP)，Business Recovery Plan (BRP)，Continuity of Operations Plan (COOP)，Incident Response Plan (IRP)，Occupant Emergency Plan (OEP)，Disaster Recovery Plan (DRP)等计划，在此我们主要介绍灾难恢复计划（Disaster Recovery Plan 或 DRP）的制订过程及方法
相比于其它机构和领域，IT系统更容易受到各种灾难的伤害而导致中断，特别是在许多情况下，关键资源可能属于不可控范围（如电力和电信），于是有效的灾难恢复计划、履行计划和对计划进行有效地测试对于削减系统风险与各种服务的不可用性就显得非常重要了。为了保证灾难恢复计划的成功，管理者应该做到以下几点：
1. 理解灾难恢复计划的全部过程及其在整个运行连续性计划和业务连续性计划过程中的地位。
2. 制定或复查其应急策略及计划过程并运用计划周期要素，包括预备计划、业务影响分析、备用站点选择和恢复策略。
3. 制定和复查其灾难恢复计划策略，重点在于计划的维护、培训以及对应急计划的演练。
4.1灾难恢复计划描述
简单地讲，灾难恢复计划的重点在于IT的恢复，如系统、应用、数据和相关的设施（如网络等）。灾备的主要目标是在事件发生时，能够保证全部或部分计算机服务的持续可用。灾难恢复计划就是指，在灾难发生时需要采取的响应步骤的详细过程。
灾难恢复计划包含了一系列灾难发生前、过程中和灾难发生后所采取的动作，灾备方案计划书应该文档化，并经过充分的测试，以保证灾难处理过程中各种操作的连续性和关键资源的可用性。
根据灾难发生的时段或业务中断的严重程度的不同，一个企业的生存能力也依赖于管理层重建其关键业务的能力。一般来讲，这些业务功能的重建需要几年的时间。但是，对于管理层，必须在几个小时或几天的时间内重建，确实是一个难题。重建复杂的商业环境要求有一个经过慎重考虑且具体的计划，以备在灾难发生时执行。从这份计划中我们可以看到，为恢复初始环境，在重建过程中应该采取的步骤。
在一个组织中，灾难的发生是不可预测的。对客户而言，最想知道的事情是灾难什么时候发生。系统和工作人员可以应对灾难，并对可预知的灾难进行反应是最终的目标。换句话说，灾难发生时，不需要等待，而只需要确定你的计划是否可行。
灾难发生时，客户、供应商和员工通常会关心中央处理设备的停机时间。在这种情况下，这些人都没有什么过分的要求，只关心停机的等待时间，而停机时间的多少则依赖于灾难恢复方案。通常，这种停机时间可以分为以下两个部分：
a) 服务丢失
表示从灾难发生到系统恢复正常所损失的时间。
b) 数据丢失
表示用户数据的丢失，也就是说，系统恢复到灾难发生前的数据层面，要花费多少时间可以重新工作。
一个组织的大部分收入，如果过分的依赖于生产系统，一旦应用和网络停机，则将会造成巨额收入的损失。在不同的行业，如果以小时为单位计算收入损失，因灾难而造成的收入减少也是不同的，如能源、电信、制造行业和金融部门，造成巨额收入的损失并不惊奇。另外，实际收入损失所占的百分比也和运营的关键业务有关系
总之，灾备计划就是要保证灾难发生后，能及时地按照一定的策略、过程和技术等方法迅速恢复IT系统、操作和数据。


第五章 典型方案介绍


5.1 基于软件的数据备份技术
在应用软件进行灾难备份的解决方案中，应从下面三个层次考虑：
   用户应用程序
   客户机软件
   数据库引擎
其中用户应用程序和客户机软件一般不包含关键数据，几乎所有数据都由数据库引擎管理并放置在数据库服务器中。在这三者之中，数据库中的数据保护最为重要。
一般情况下，用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份，当灾难发生时，可以通过这些备份重新安装和配置用户应用程序和客户机软件。
对数据库的备份，如果采用硬件级灾难备份有两种方法：一是采用备份的方法，即定期地将数据备份到硬盘和磁带/磁带库上，这些磁带可以通过运输的方式运到远程，以防磁带在本地的灾难中发生毁坏。这种方法的缺陷是实时性较差，恢复时间较长；另一种做法就是硬件镜像的做法，这种做法在硬件的投资上较大，对两点间的网络带宽有较大的要求。那么，有没有一种两者兼顾的解决方案呢？数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。在前面提到的灾难恢复方案的7个层次中属于第5或第6层次。
数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。目前已有的产品有DSG Realsync、IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。
IBM DB2 HADR是High Availability Disaster Recovery 的缩写，HADR 将HA（高可用性）和INFORMIX DR的技术紧密结合起来。INFORMIX HDR是High Availability Data Replication的缩写。
HDR的工作原理是通过将主数据库服务器（简称为A）的逻辑日志缓冲区复制到备份数据库服务器（简称为B），而且能在主数据库服务器操作失败时自动切换到备份数据库服务器。复制方式有同步方式和异步方式两种。我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。

正常状态下，主数据库服务器做数据库的读写操作，备份数据库服务器为只读方式。当主数据库服务器失败时，备份数据库服务器会自动接管主数据库服务器的事务处理。此时，备份数据库服务器作为主数据库服务器进行数据库的读写操作。当主数据库服务器被修复后，主数据库服务器作为新的备份数据库服务器。

此时备份数据库服务器虽为只读方式，但并不是空闲的。它可以分担主数据库服务器的负载，例如执行查询、出报表等任务。

数据库复制对硬件的要求相对较低，只要主数据库服务器和备份数据库服务器的硬件配置相同即可，不是必须使用高端存储设备，例如IBM ESS等。主数据库服务器和备份数据库服务器的距离不受限制，而且对网络的压力并不大，但需要更强的数据库管理能力。
下面介绍一下HDR的工作原理。如下图所示：

在逻辑日志缓冲区（Logical Log buffer）刷新之前，它里面所有的交易（Transaction ）将拷贝到数据复制缓冲区（Data Replication Buffer）。数据复制缓冲区的大小和逻辑日志缓冲区相同。数据复制缓冲区通过TCP/IP网络将数据发送到备份数据库服务器的数据复制缓冲区中。在备份数据库服务器端，一个数据复制线程接收数据复制缓冲区的数据并把他们放入到恢复缓冲区（Recovery Buffer）. 另一个数据复制线程（或一些线程）记录数据库日志信息。主数据库服务器和备份数据库服务器都有一个“Ping”线程在运行，它会定时唤醒并且检查两个数据库服务器的连接。如果任何一台服务器上的“Ping”线程检测到连接中断，都会发一条出错信息到消息日志中。
HDR有两种复制方式：同步方式（Synchronous）和异步方式（Asynchronous）

在同步复制的方式下，主数据库服务器的逻辑日志缓冲区只有在下面的过程完成后才可以刷新：
1. Copy: 逻辑日志缓冲区数据拷贝到数据复制缓冲区；
2. Send: 数据从主数据库服务器的数据复制缓冲区通过网络传送到备份数据库服务器；
3. Acknowledge:当备份数据库服务器接收到数据后发回确认信息；
4. Flush: 此时，主数据库服务器才可以刷新其逻辑日志缓冲区的数据。
采用同步方式的优点是两边数据库服务器的数据一致，但是由于每笔在主数据库服务期提交的交易需要发送到备份数据库服务器而且得到确认后才算真正成功完成，由此而产生的时间延迟会使性能受到一定的影响。
如果采用异步复制方式，主数据库服务器的逻辑日志缓冲区只要在逻辑日志缓冲区的数据拷贝到数据复制缓冲区之后就可以进行刷新了。这样做的缺点是在某些系统失败的情况下，可能会有一些数据还没有来得及通过网络传送到备份数据库服务器；优点是主数据库服务器的性能不受影响。
对于Oracle DATA GUARD的工作原理，大致上与IBM HADR 和INFORMIX HDR的工作原理类似。
Oracle9i DATA GUARD 通过使用称为备份的数据库来防止数据灾难的出现。它通过将源数据库的重做日志传输并应用到备份数据库中，来使备份数据库与源数据库同步：
   可以将重做日志直接从源数据库同步的写到备份数据库，来完成零数据损失的灾难保护，这会给源数据库的性能带来一定的性能损失。
   可以将归档的重做日志从源数据库异步的写到备份数据库，来使源数据库在极少的损失性能的前提下，最小化地减少数据的丢失。
   如果重做日志数据到达备份数据库后就快速应用到备份数据库，则在源数据库出现问题时便可以快速地切换到备份数据库。然而，如果延缓一定时间后再应用重做日志数据，就可以避免源数据库的错误快速地传播到备份数据库。
DATA GUARD同样也有同步和异步复制两种方式可以选择。

附录A.容灾方案演示环境
6.1基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境

.图：基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境拓扑图
6.1.1应用环境基本需求
1. 硬件环境配置
本地生产中心：
   IBM xSeries 445(4 CPU, 2GB内存) 1 台
   Qlogic 2310光纤通道卡 2 块
   IBM 2109-F16光纤交换机 2 台
   IBM ESS800 企业级存储服务器 1 台
   客户端PC机 若干
远程备份中心：
   IBM xSeries 445(4 CPU, 2GB内存) 1 台
   Qlogic 2310光纤通道卡 2 块
   IBM 2109-F16光纤交换机 2 台
   IBM ESS800 企业级存储服务器 1 台
   客户端PC机 若干
   软件环境配置
   Microsoft Windows Advanced Server(Service Pack 3)
   Qlogic 2310: Bios level 1.35 驱动程序 8.2.2.61
   ESS SDD 1.5.0.1
   ESS 800 微码版本: 2.3.1.124
   ESS Flashcopy 版本2
   ESS PPRC 版本2
   IBM 2109-F16固件版本：3.0.2f
3. 网络环境配置
本环境中的网络部分由两部分组成：
第一部分为公网部分，主要承担应用环境中，服务器与服务器之间，服务器与客户机之间的网络通讯；该部分使用10.1.1.X网段，子网掩码为255.255.255.0。
第二部分为管理网段，主要承担应用环境中存储服务器ESS800、光纤交换机的通讯，这里我们命名为ESSNet。该部分使用172.31.1.X网段，子网掩码为255.255.255.0。
4. SAN环境配置
本环境中在本地生产中心和远程备份中心各配置有独立且冗余的光纤交换机。本地生产中心和远程备份中心的每台服务器都至少配置有两块光纤通道卡。本地生产中心和远程备份中心的存储服务器IBM ESS800配置有4块光纤卡，其中两块光纤卡用于服务器与ESS800的连接；另外两块光纤卡分别应用于本地生产中心和远程备份中心的ESS800之间的专用光纤数据链路。本地生产中心和远程备份中心的光纤卡都通过冗余的方式连接到光纤交换机上。本地生产中心和远程备份中心的光纤交换机采用光纤电缆级联起来，构成一个统一的光纤网络。
6.1.2基于磁盘系统的PPRC数据容灾及恢复过程
利用上述典型应用环境，可以实现对相应的生产系统数据进行容灾备份。
PPRC进行数据恢复非常简单，由于数据在远程同步保存着同样的数据，因此主机部分的容灾操作仅需要在远程重新启动主机，而恢复过程则可以反向执行初始化操作。具体过程如下（只考虑主机、存储部分）
a. 灾难发生
(1) 确认灾难，如果需要切换则执行下一步（可自动，但最好由人工控制）；
(2) 在远程备份中心停止复制操作（数据复制已经停止，只是释放此数据卷）；
(3) 启动远程备份中心主机，主机、数据恢复过程完成。
b. 灾难恢复
(1) 确认原生产中心正常；
(2) 反向建立数据复制对；
(3) 开始同步数据；
(4) 暂停容灾中心业务，然后停止同步过程；
(5) 在生产中心重新启动业务，切换网络，业务恢复；
(6) 建立正向数据同步复制对，容灾业务恢复。
附录B.术语
中文                                                英文
活动状态的备份中心       Active Secondary Center
高级对等网络                  APPN，Advanced Peer to Peer                                                Networking
美国电话电报公司          AT&T, American Telephone and                                           Telegraph
异步传输模式                 ATM，Asynchronous Transfer Mode
业务连续计划                 BCP, Business Continuity Plan
边界网关协议版本4        BGP-4，Border Gateway Protocol -                                            4
基本输入输出系统          BIOS，Basic Input/Output System
底线                               Bottom Line
业务恢复计划                 BRP, Business Recovery Plan
业务连续性                     Business Continuity
业务影响分析                 Business Impact Analysis
层叠                               PPRC Cascading PPRC
危机通信计划                 CCP, Crisis Communication Plan
首席信息官                     CIO，Chief Information Officer
命令行接口                     Command Line Interface
运行连续性计划              COOP, Continuity of                                                               Operations Plan
信用事件                         Credit event
客户关系管理（软件）   CRM, Customer Relationship                                                    Management
数字数据网                     DDN，Digital Data Network
"灾难"恢复                      Disaster Recover
降级操作                         DOO, Degraded Operations Object
灾难恢复计划                  DRP, Disaster Recovery Plan
增强版内部网关路由协议EIGRP，Enhanced Interior Gateway                                            Routing Protocol
电子链接                          Electronic Vaulting
电子链接                          Electronic vaulting
企业系统连接                   ESCON，Enterprise System                                                         Connection
企业级存储服务器           ESS, Enterprise Storage Server
故障切换                          Failover
光纤连接                          FICON，Fiber Connection
地理分布并行系统           GDPS，Geographically Dispersed                                             Parallel Sysplex
高可用性集群多处理软件 HACMP, High Availability                                                         Cluster Multi-Processing
高可用性灾难恢复            HADR, High Availability Disaster                                            Recovery
IBM的一种灾备软件          HAGEO，High Availability                                                           Geography
热交换中心                        Hot Center
国际数据中心                     IDC，International Data Center
事件响应计划                     IRP, Incident Response Plan
管理信息系统                     MIS，Management Information                                                Systems
没有异地数据                     No off-site Data
网络恢复目标                     NRO, Network Recovery Object
场所紧急计划                     OEP, Occupant Emergency Plan
开放最短路由优先协议       OSPF，Open Shortest Path First
PTAM卡车运送访问方式       Pickup Truck Access Method
快照                                   Point-in-time Copies
PPRC镜像对                        PPRC Pairs
对等远程拷贝                     PPRC, Peer-to-Peer Remote Copy
距离扩展的对等远程拷贝  PPRC/XD, Peer-to-Peer Remote                                             Copy/Extended Distance
应用版本的一致性             PTF
磁盘冗余阵列　                 RAID，Redundant Array of Disks
恢复时间点 RPO,               Recovery Point Object
一种串行通信端口             RS232
恢复时间                            RTO, Recovery Time Object
存储区域网络                    SAN, Storage Area Network
小型计算机系统接口         SCSI，Small Computer System                                                Interface
一家商用软件供应商          Siebel
系统网络结构协议             SNA，System Network                                                                  Architecture
光谱共同基金                     Spectra mutual fund
备用服务器                         Standby Server
存储系统级别                     Storage Device Level
子系统设备驱动程序          Subsystem Device Driver
外宕机                                System down
层次                                    Tier
两数据中心，两个阶段的数据传输承诺                                                                                 Two-Site Two-Phase Commit
虚拟磁带服务器                  VTS, Virtual Tape Server
0数据丢失                            Zero Data Loss
Trackback:
http://tb.donews.net/TrackBack.aspx?PostId=781309
[/url]
               

本文来自ChinaUnix博客，如果查看原文请点：[url]http://blog.chinaunix.net/u3/93145/showart_1892112.html