第1章前言

在企业信息化进程不断加快的今天，保持业务的连续性是企业用户进行数据存储时必须考虑的重要方面。灾难的出现可能导致生产停顿、客户满意度降低，减少企业的竞争力。如何安全、可靠、完整地保存数据，实现系统的灾难恢复是市场竞争的需要，更是进一步提高服务水平和改善服务质量、提升业务支撑能力的重要技术手段。

“911”事件使大家更加谨慎地审视自己的应用系统。据有关数据表明，接近50%的公司需要关键业务24小时连续运作，但是在这些公司中，有67%的公司没有在其他地方拥有冗余的计算机设备，79%的公司没有后备的关键业务系统，86%的公司没有适当的备份计划和数据恢复计划来保证业务的连续运行。在9月11日纽约世贸中心惨剧发生之后，所有世贸大楼公司的商务资料在瞬间毁于一旦，有些公司由此退出了市场的角逐。而一些公司却得益于自己的灾备系统，从而保住了公司依赖生存和发展的资本-数据。

容灾系统的建设包括两个重要因素，即业务系统的连续性和业务数据的可恢复性。在“911”事件以前，很多企业的高可用性方案主要从应用系统的连续性考虑。其中最普遍采用的是通过高可用集群双机系统(Cluster或HA)对业务应用提供保护，在一台服务器的软硬件发生故障时，将整个业务切换到后备服务器上。该方法很大程度上避免了服务器的单点故障，提高了整个业务系统的可用性。但从整个应用系统的角度，高可用集群只能实现一部分的高可用性目标。例如它无法处理存储设备故障，也无法处理计划内的停机时间和容灾恢复。在数据的可恢复性方面，主要采用的技术是各个层次的备份和恢复机制。但对于海量数据的备份和恢复存在一定的难度，而且备份恢复一般局限于本地，在出现类似”911”的灾难时无法进行有效的恢复。

所有这些都要求企业重新设计和建立自己的高可用性和容灾系统。对于业务严重依赖于数据的企业来说，此系统必须包括保证应用系统的连续性，并提供有效的数据恢复机制。应用系统的连续性则应该从最终用户的角度来衡量，以整个系统的停机时间和可接受程度作为评价标准。数据恢复规划则需要以企业IT人员的视角来进行，肩负着在真正灾难发生时维系企业命脉的责任。

目前，很多厂家都提供容灾保护的产品，主要包括基于存储、逻辑卷、主机、数据库物理方式和数据库逻辑方式的各种复制技术。根据复制层面的不同，实现的技术以及容灾效果各不相同。Quest Software的SharePlex for Oracle通过数据库逻辑层的复制技术，可以方便地实现基于Oracle数据库的容灾保护，具有对源系统资源占用少，对网络资源占用少，支持异构环境和不同的复制拓扑，保持事物一致性的特点。在开放异构环境、异地容灾、容灾系统可访问的环境中具有非常大的优势。

通过SharePlex for Oracle，可以帮助企业建立一个全面的、整体的容灾方案，最大限度地保证业务系统的连续性和业务数据的可恢复性。

第2章高可用容灾方案设计

2.1 高可用容灾系统的影响因素

影响应用系统可用性主要有三方面的因素，计划外的系统停机、计划内的维护操作和灾难恢复。

2.2 高可用容灾系统的建设目标

系统的容灾和高可用方案必须能够应付所有可能引起计算机系统失效的问题。应用系统高可用性和容灾方案需要满足两方面的要求：

1．业务系统的连续性

保持业务系统的连续性，意味着无论是由于硬件，软件或电源的失效都不应中断信息中心的处理工作；实现业务的连续性需要减少或消除计划外停机时间，控制计划外停机时间对系统的影响，在灾难发生时间进行业务系统的快速接管，这些主要通过各个层次的冗余技术实现的。

2．业务数据的可恢复性

业务数据的可恢复性从本质上来说是业务系统连续性的一个子集。如果数据出现问题而不能恢复，业务系统的连续性无从谈起。因为数据对严重依赖于信息系统的企业非常重要，数据的可恢复性一直是高可用性系统的一个重点考虑因素。业务数据的可恢复性是通过数据备份和冗余的数据拷贝完成的。数据库复制和硬件复制都是用于这个环境的一些成熟技术。业务数据的可恢复性主要考虑因素为备份数据的安全性，需要确保在任何情况下，包括容灾发生时备份数据都可以有效地进行恢复。同时，数据丢失也是一个非常重要的评价指标。

2.3 建设容灾系统的考虑因素

因为要建立整个应用系统的冗余备份，容灾系统是一个非常昂贵的系统，在容灾系统建设时需要考虑以下因素：

（1）容灾距离：

根据灾备中心建设的目的不同，灾备中心的建设需要考虑灾备中心的距离。一般来说，容灾距离有本地和同城、异地三种方式。

异地容灾方案中，灾备中心和主中心的距离较远，如北京到上海。异地容灾可以有效地防止由于本地灾难发生引起数据损失，但是实施成本很高、为了保障业务系统的性能一般采用同步数据拷贝方式，这样会存在一定的数据损失，同时将应用系统切换到灾备中心的工作也非常繁琐。一般来说，异地灾备中心建设的主要目的提供业务数据的恢复能力。

同城容灾方案中，灾备中心和主中心距离在几十公里以内。同城容灾可以有效地提供业务数据的恢复能力以及应用快速接管能力。根据业务系统对数据访问以及数据丢失的需求，数据复制可以采用同步或异步两种方式。

同地容灾指灾备系统和主中心在一个地理位置。一般来说，它可以和现有的其他可用性技术，如Cluster结合，提供更高级别的高可用性。同时，很多同地容灾解决方案提供灾备中心的数据访问能力。

为了有效地进行容灾，很多关键的业务系统建立两个系统，同城灾备中心和异地灾备中心，同城灾备中心由生产系统采用同步方式进行数据复制，异地灾备中心由同城灾备中心采用异步方式进行数据复制。

（2）数据丢失

企业能忍受的数据丢失和具体处理的业务有关。例如：财务系统的数据很难承受任何损失，而电信营帐系统在灾难发生时可以允许少量的数据丢失。目前，虽然有很多方案可以做到“零数据丢失“，但企业往往为此支付高昂的费用，生产系统的性能也会受到很大影响。从业务的角度企业能够承受德考虑数据丢失问题可以帮助企业在容灾方案上做出适合企业自身特点的选择。

（3）应用切换时间

容灾系统建设的一个重要目的是保障业务系统的连续性。在灾难发生或业务系统出现问题时间，将应用快速地切换到灾备系统可以最大程度地减少系统的停计时间。当灾难发生，启用灾备中心需要采取一系列的措施。如将网络、电话线路切换到新的地点，启动操作系统、数据库，进行应用程序的切换等等。一般来说，容灾系统的切换时间应该控制到30分钟以内。

（4）主系统的可恢复性

主系统的可恢复性主要指数据的恢复，将应用切换灾备系统后，业务的连续性得以保持，主系统的恢复时间应该控制在一天到几天之内。数据恢复的关键问题在于数据的可恢复性，以及恢复过程中如何和灾备中心的数据保持一致。

（5）目标系统的可访问性

目标数据可访问能够提高容灾系统的投资回报，增加容灾系统的利用价值。企业可以将目标系统作为报表查询、统计分析等系统的数据源，减轻源系统的压力，使投资变为可用，而不是单存的冷备闲置。同时，目标数据的在线使用可以保障数据的准确性，从而避免容灾系统长期冷备，数据错误而无人发现的情况，能够确保容灾系统在灾难发生时被有效接管，进行数据恢复。

（6）对源系统的影响。灾备中心的建设是对现有系统的扩展和补充，不能因为灾备中心影响当前业务系统的性能，导致系统的可用性降低。

（7）网络资源的使用。网络资源的使用对于容灾系统特别是异地容灾系统非常重要。在网络上传输的数据量大小直接决定数据传输的实时性，同时，网络资源占用会影响灾备中心后期的网络使用费用。

（8）容灾环境的开放性。组成数据库应用系统的环境非常复杂，主机、存储、数据库是容灾环境的三个主要组件，支持开放环境，例如容灾系统支持不同的操作系统和数据库、不同的磁盘阵列、不同的主机系统会有效地适应未来的扩展需求，充分保护投资。

实施成本是在充分评估了上述内容后需要考虑的又一个重要因素。事实上，在建立容灾系统时，一个对业务系统没有任何影响、没有任何数据损失、容灾距离足够远的方案是很难实现的。企业需要了解自己的需求，建立适合自身特点的容灾系统。双数据中心环境下的有效冗余和网络结构

2.4 容灾系统的实现技术

2.4.1 基于磁带拷贝的传统灾难备份方式

利用磁带拷贝进行数据备份和恢复是最常见的传统灾难备份方式。这些磁带拷贝通常都是按天，按周或按月进行组合保存的。

使用这种方式的数据拷贝通常是存储在盘式磁带或盒式磁带上，并存放在远离基本处理系统的某个安全地点。存储到安全地点的磁带拷贝，其上的数据已有数小时的延迟，而在灾难或各种故障出现系统需要立即恢复，必须将磁带提取出来，并运送到恢复地点，通常还要滞延几个小时。

基于磁带拷贝方式的传统灾难备份方式有着明显的缺陷，越来越不适合用户不断发展的业务系统的需要。其备份和恢复过程非常复杂，数据延迟较大，磁带管理困难，数据恢复必须按照正确的顺序，出错的可能性也较大。

2.4.2 数据库方式

数据库复制是目前最流行的高可用解决方案。每种数据库系统来实现的机制和方式略有不同，但都包括逻辑复制和物理复制两种方式：

逻辑复制指针对数据库的逻辑层数据进行复制，复制的基本单位为数据库表以及表中所有的数据，复制时采用标准的TCP/IP协议。这种复制方法的好处是复制的数据量少，网络资源占用低，在复制的过程中目标数据库可以被访问，企业可以将目标系统用于报表和查询系统。同时因为目标数据库处于启动状态，接管时不需要重新启动数据库，接管可以接近实时。

物理复制方法主要通过日志文件的传送和应用实现的。数据库交易的复制机制利用日志的这种特性，在生产中心将日志传输到灾备中心；如果灾备中心的数据库结构和生产中心的数据库结构保持一致，则灾备中心的数据库对日志中记载的交易执行前滚操作，即实现了对灾备中心数据库数据的更新。

数据库级别的复制可以支持计划内停机时间、计划外的停机时间和应用可以允许一些损失的情况下进行灾难恢复。

2.4.3 服务器卷方式

服务器卷方式复制嵌入到操作系统的卷管理系统中，卷发生的变化分为结构的变化和卷内容的变化。这种复制方式可以复制卷内容的变化。

服务器卷方式有两种复制方式，同步方式和异步方式。同步方式采用数据库两阶段提交的方法，对源系统的影响非常大。异步方式从数据的一致性保障方面存在问题。

由于卷复制部件使用服务器CPU、Memory资源，使用标准的TCP/IP网络，对业务的正常运行产生的较大的性能影响。

使用服务器卷方式进行复制，必须使用专用的卷管理软件，整个应用系统的结构需要根据卷管理的要求经过严格的设计和重新划分，同时，在后期的维护过程中也需要对卷结构的变化进行同步的维护，从而增加实施和维护方面的一些困难。

服务器卷方式复制对服务器的硬件平台、数据库版本有严格限制，局限于主机同构环境。

2.4.4 智能存储系统方式

智能存储方式利用磁盘系统自身的处理能力，通过磁盘系统之间的通道连接复制磁盘系统内的数据更新，从而在异地中心保存生产数据的记录。利用磁盘复制可以独立于服务器、操作系统、卷管理系统、数据库、文件系统、中间件、应用程序。

和服务器卷方式一样，智能存储两种复制方式，同步方式和异步方式。同步方式采用数据库两阶段提交的方法，对源系统的影响非常大。异步方式从数据的一致性保障方面存在问题。

智能存储系统方式复制使用存储上的CPU资源，但对IO资源的消耗比较大。这种方式复制速度很快，但这种复制方式对存储依赖非常强，主备服务器必须使用同样的存储设备，依赖于专有网络。因为在存储级进行复制，目标数据库处于不可用状态。当需要应用切换时，必须停止复制过程，Mount复制卷组，将操作系统启动，启动数据库，进行数据库恢复。所有这些工作一般手工进行，需要花费一定的时间。

采用智能存储系统方式进行复制，源系统和目标系统的硬件平台、操作系统、数据库版本必须一致。复制的内容包括所有底层数据，占用的网络带宽较高。而且目标系统无法访问。

第3章 SharePlex for Oracle介绍

3.1 SharePlex for Oracle结构

(1)基本结构

下图所示为SharePlex for Oracle的基本结构，其中涉及较多的技术细节。

(2)数据捕获

SharePlex for Oracle中由捕获进程来收集发生变化的数据，此进程的独特之处在于它几乎不对生产数据库带来任何开销。

(3)数据传输

SharePlex结合其自己的网络协议和TCP/IP协议来完成源和目标系统之间的数据传输。其相关的进程确保数据的正确接收和网络数据包的正确顺序，从而提供网络传输冗余，确保数据的完整。整个数据传输过程无需其它的中间件。

(4)应用数据

应用进程将传送到目标系统中的信息转化为SQL语句，然后采用标准的SQL*Plus方式将SQL语句发送给Oracle执行。

SharePlex能够实现精确复制的一个重要原因就是其能保证从源数据库到目标数据库的Oracle读一致性，不但按顺序复制事务，而且也复制上下文信息。由于SharePlex将源数据库中发生变化的全部事务信息都复制到目标数据库中，因此SharePlex复制方案用于灾难恢复系统中是足够可靠的。

3.2 SharePlex for Oracle配置方案

SharePlex提供多种不同的配置方式以满足高可用性和负载均衡需求。主要包括：

（1）单向复制

SharePlex可以将源系统的数据实时复制到目标系统，从而建立一个可以被访问的即席查询和报表系统。目标系统可以是源系统的全集和子集。通过将查询和报表系统放在不同的数据库实例中运行，可以平衡服务器负载并提高OLTP类生产系统的性能。

（2）高可用性

保证数据高可用性和数据库系统能够从灾难中迅速恢复是一个非常具有挑战性的工作。SharePlex for Oracle可以通过LAN或WAN进行复制，这样当生产环境出现紧急事件或要进行例行维护时，可以将应用切换到复制数据库中。有了生产数据库的实时拷贝，用户可以保证应用系统7*24不间断运行的情况下进行维护工作，如进行操作系统和数据库的升级等等。

（3）分布处理

多数据源配置允许你将不同的用户分布到不同的服务器，让每个数据库能够反映其他数据库的变化。在这种配置模式下，SharePlex采用必要的冲突处理机制来解决可能发生的冲突。

（4）广播和集中复制

SharePlex for Oracle通过LAN或WAN进行实时复制，将生产数据库中的数据拷贝到需要它们的地方。对广播复制来说，远程用户可以访问这些实时数据而不用登录生产服务器。因此，提高了网络性能和生产环境下的OLTP应用的性能。

（5）企业环境的数据分布

SharePlex 支持层叠复制，可以向不是直接相连的数据库复制数据。使用这种配置，可以在远程数据库间进行复制（如从北京到上海）。SharePlex 支持多种复杂的场景来满足复制需求。

3.3 Shareplex for Oracle特点

3.3.1 快速精确和低负载

SharePlex是非常快速的，同时保证了复制数据的精确性。在源数据库一端，SharePlex严格地遵守读一致性模式。在目标数据库一端，SharePlex使用标准SQL提交事务，并保证操作次序和会话上下文的一致。

基于Log的复制方式对源数据库和系统所带来资源开销非常小，因为复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。

3.3.2 可扩展及全面

每秒钟可针对数千个表复制超过一千个以上事务的处理能力意味着SharePlex可以处理企业级的业务数据，可以满足企业大数据量的吞吐需求。实际环境中的吞吐速率是受服务器性能、网络带宽和事务的复杂程度所影响的。

SharePlex 提供的完全复制程度是其它软件复制工具所不具备的。SharePlex支持带长列的表、带参照完整性约束的表、没有主键的表、序列等等的复制。此外，SharePlex复制ALTER TABLE等命令，使它可以不需要其它软件复制工具就复制DDL活动。

3.3.3 灾难恢复

SharePlex在设计时已经将性能和容灾因素考虑在内。SharePlex可以容忍实例失败、系统失败和网络失败。一般情况下，在源系统中运行的事务一旦被写入log，SharePlex立即将其发送到目标系统。然而，如果发生问题，SharePlex可以在源系统或目标系统进行事务排队(为了最小化对源系统的影响，排队位于Oracle源实例之外)。例如，如果网络宕掉或目标系统宕掉，SharePlex将源系统中的事务排队。当网络或系统恢复后，SharePlex将自动提交被排队的数据并清空队列文件。

3.3.4 灵活配置和简洁管理

SharePlex可以被灵活配置，以支持各种复制策略。包括单向复制、双向复制、广播复制、集中复制及多层复制等。

SharePlex是独立的软件，不需要修改与数据库进行交互的应用程序和数据库本身。因此，安装非常简洁。配置和改变复制策略不影响源数据库系统中的生产活动。管理员可以用Windows界面或服务器端的命令行管理和监控复制操作的各个方面。

3.4 SharePlex for Oracle适用场合

(1)应用容灾

企业开始比以往任何时候更注重对关键业务数据进行及时的保护，因为关键业务数据的丢失可能会给企业带来不可估量的损失。

SharePlex为业务系统提供灾难恢复能力，容灾系统中的硬件环境又可用来降低系统维护工作中的停机时间。这并不与企业的容灾方案相矛盾，因为事务可被发送到系统中的远程节点上。

SharePlex支持多种配置方案，包括对等配置方案，在这种配置方案中，两个数据库都处于可用状态，因而可实现快速的失败接管。在容灾发方案中没有比这种失败接管更快的方法了。

(2)减少有计划的停机时间

有计划的停机也可能对企业的服务水平、客户满意程度甚至股价等带来影响，而据估计企业80%的停机是有计划的行为。

利用SharePlex，企业可几乎完全消除系统的停机时间而不用考虑在此期间进行何种维护工作、哪个操作系统会受到影响，甚至不用考虑数据库版本的问题及对硬件环境进行何种操作。

(3)负载平衡

SharePlex 可以将源系统的数据实时复制到目标系统，从而建立一个可以被访问的即席查询和报表系统。目标系统可以是源系统的全集和子集。通过将查询和报表系统放在不同的数据库实例中运行，可以平衡服务器负载并提高OLTP类生产系统的性能。一方面，可以减少OLTP应用和查询报表应用之间的磁盘I/O冲突，提高OLTP应用的效率。另一方面，SharePlex支持不同模式间的复制。可以分别面向OLTP和查询系统的使用特点来进行设计，如建立索引，设置数据库表的参数等等。

在这种配置环境下，SharePlex在线事务处理可以获得很好的性能，而决策支持和报表处理可在不影响正常业务的情况下进行。

当一种单一的数据复制模式不能满足企业的业务扩展需求和系统性能时，很容易利用SharePlex建立另外的复制模式，从而进一步扩展系统和提高报表处理的性能。

(4)系统移植

尽管企业从规划设计良好的业务系统中收益，但也不得不面临系统移植和升级这一挑战。数据集中、技术的推陈出新和服务器的移植都是导致必须进行系统移植的原因之一。

SharePlex可确保在进行以上工作时正常的事务处理得以继续进行。源系统的功能不受到任何影响，SharePlex只捕捉移植过程中发生变化的事务并将它们排队保存。当移植工作结束后，这些被保存的事务将被应用到新系统中并进行数据同步工作。一旦数据同步后，用户活动会有非常短暂的停顿，在此瞬间将完成系统的切换动作。

(5)数据集中和广播

SharePlex通过非常有效的管理控制机制来实现数据集中和广播。SharePlex提供细化的数据筛选功能，可按业务需要定制需要传输的数据，从而缓解和消除了数据传输过程中的安全和带宽问题。例如，如果远程节点只需要有关本地员工的基本信息而无需薪水信息，那么只需利用SharePlex传输相关的数据行和字段即可。

(6)支持数据仓库应用、实现更好的决策支持

越来越多的公司在建设决策支持系统。传统的数据抽取、转换和装载工具按照时间段处理数据而不能进行实时的数据处理，因而决策支持系统就不能真正体现出太大的价值。SharePlex可以实时捕捉、转换数据到决策支持系统中。

第4章容灾系统的操作流程

4.1 容灾系统状态定义

为方便论述，本节模拟地点A和B，两地各有一套运行在Oracle上的应用系统。通过SharePlex for Oracle建立数据复制，以B地点的系统作为A地点的备份。

一、正常情况下：

ü 业务系统运行在地点A，包括数据库实例、有关的文件、数据库数据、应用软件。A节点对外提供服务。

ü A节点所有的有关的数据通过SharePlex for Oracle实时复制到B节点。

二、灾难发生的情况下，整个A地点无法正常提供服务：

ü A地点的业务将在B地点正常提供服务。当灾难发生时，主中心的数据库服务、应用软件切换到灾备中心的灾备节点。灾备节点对外提供服务。

ü 数据复制暂停。

ü 对主中心的数据库和应用系统进行恢复。

三、计划内维护操作

ü 当进行计划内的维护时，主中心的数据库服务、应用软件切换到灾备中心的灾备节点。灾备节点对外提供服务。

ü SharePlex for Oracle记录进行维护期间数据的变化，存储到灾备节点的队列。

ü 当计划内的维护操作时完成时，将维护过程中的数据复制到A地点，将应用切换到A地点系统。

4.2 容灾系统的的配置过程

4.2.1 初始化高可用及容灾环境

使用SharePlex for Oracle进行数据复制的前提是在主中心和灾备中心具有相同的数据。根据用户对停机时间的要求、容灾环境和数据量的大小。可以采用Oracle自身提供的方法进行初始化同步，包括：Oracle Cold Backup，Oracle Hot Backup，Export/import，Transprant tablespace等等。

为了保证初始化同步过程中源系统的可用性，SharePlex 提供Reconcile 功能，当使用Oracle Hot backup 机制进行初始化同步时，通过SharePlex队列记录数据的变化。并在进行post的过程中确认哪些数据通过Recovery进行恢复，把没有恢复的数据装载到数据库中。从而保证初始化同步过程中源系统没有停机时间。

4.2.2 配置Shareplex的Fail-over ready状态

为保证灾难发生时快速进行应用接管，需要配置Fail-over ready状态。

ü 确保源系统和目标系统SharePlex for Oracle启动。

ü 源系统中建立配置文件，目标系统建立反向配置文件。两个配置文件都处于激活状态。

ü 在Secondary端保证没有对复制表的DML操作；

ü 在Secondary端停止export进程，防止意外的数据操作改变源系统的数据。

ü 运行脚本取消secondary系统用户(除了splex)的insert,update和delete权限；

ü 禁止Secondary中使用trigger，cascade delete constraints,foreign-key constraints,check constrants,schedule jobs等等。

ü 定期备份Shareplex相关的文件，文件包括

1) Shareplex的工作目录

2) /var/adm/.splex/Shareplex.mark

7) 操作系统Shareplex用户（默认为Oracle用户）的.profile文件

4.2.3 灾难发生时应用切换到灾备中心

灾难发生时的接管工作由以下步骤组成：

ü 确认Secondary系统的export进程处于停止状态；

ü 确保在队列中的所有数据复制到Secondary系统中。用qstatus命令查看Secondary系统中的post进程，直到backlog messages一项为0；

ü 在Secondary系统上运行SQL脚本给用户赋权，包括insert, update和delete；

ü 在Secondary系统上运行SQL脚本enable triggers和contraints；

ü 切换应用系统到Secondary系统；

ü 确保Secondary系统上的Shareplex export进程处于停止状态。

切换过程所需要的时间主要是上述6个步骤所需要的时间的总和。正常情况下能够充分满足30分钟以内的切换要求。

4.2.4 容灾中心的数据恢复到主中心

从容灾中心的数据恢复到主中心的过程分为如下阶段：

ü 阶段1：在Primary System中恢复复制环境。

ü 阶段2：Purge队列，在Primary System中Purge Capture,Export和Post队列。因为Primary System的复制环境是通过备份的软件进行恢复的。队列的内容已经过期。在Secondary System中Purge Post队列。原则上Capture和Export队列没有内容，而在Post队列中需要清除没有被提交的部分数据。

ü 阶段3：开始从Secondary system复制到Primary System，保证Primary System的数据存储在Post队列中，但不加载到数据库中。

ü 阶段4：同步数据，即在Primary System中重新建立新的数据库拷贝。

ü 阶段5：在Primary System中进行Activate。

ü 阶段6：恢复Object Cache。

ü 阶段7：将用户切换到Primary System。

系统的恢复时间由上述的7个阶段构成，其中阶段4的时间较长，根据系统的数据量、目标系统硬件选型不同，正常切换时间在10-38个小时之间。

4.2.5 计划内系统维护

4.2.5.1 计划内的Shareplex failover接管

ü 在Primary系统上停止用户对数据对象的访问；

ü 在Primary系统，运行flush命令，此命令停机目标机器上的post进程，并将队列中的内容装载到数据库中。

ü 关闭Primary中的SharePlex和Oracle数据库。

ü 运行脚本为Secondary系统的oracle用户赋insert, update和delete的权限；

ü 运行脚本激活Secondary系统的oracle trigger和contraints；

ü 按照相应步骤重新部署用户和应用到Secondary系统；

ü 切换用户到Secondary系统，但不要启动export进程；

4.2.5.2 计划内的Shareplex failback接管

ü 打开Primary系统的Oracle数据库；在Primary系统上对Triggers、Foreign-key constraints、Cascading delete constriants、Check constraints、Scheduled jobs that perform DML进行修改并使之无效。

ü 将Secondary系统中SharePlex 队列中的数据装载到Primary系统中。

ü 在Secondary系统上，运行flush命令；此命令停机Priamry机器上的post进程，并将队列中的内容装载到数据库中。

ü 在Secondary系统关闭shareplex和Oracle数据库。;

ü 运行脚本为Primary系统的oracle用户赋insert, update和delete的权限；

ü 运行脚本激活Primary系统的oracle trigger和contraints；

ü 按照相应步骤重新部署用户和应用到Primary系统；

ü 切换用户到Primary系统，但不要启动export进程；

ü 运行脚本取消secondary系统用户(除了splex)的insert,update和delete权限；

ü 在Secondary系统上对对Triggers、Foreign-key constraints、Cascading delete constriants、Check constraints、Scheduled jobs that perform DML进行修改并使之无效。

ü 启动Secondary系统的Shareplex，但停止export进程；

ü 在Primary系统Shareplex控制台上启动export进程；

4.3 SharePlex 关键技术指标

4.3.1 数据延迟

SharePlex for Oracle是一种异步准实时的复制技术，其数据延迟非常小。在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，数据延迟在几秒钟。

4.3.2 强大的冗错能力

复制环境能够提供网络失败、数据库失败、主机失败的容错能力。当灾备中心暂停或传输异常中断导致复制停止时，主中心的业务不受影响，容灾数据可以在主中心暂时存放，当系统恢复后，暂存数据可自动完整复制到灾备中心，数据完整性一致性不被破坏；

4.3.3 对源系统的影响

SharePlex for Oracle通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用小于6个百分点，对内存资源的占用为几十M。

4.3.4 网络资源的使用

因为Shareplex复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。Shareplex只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3 。

例如用户峰值每小时生成的日志量为720M。

实际峰值期间每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3=720/3=240M

每秒传输的数据量=240/3600 M=1/15 M

考虑20%的传输开销，所需要的带宽为1*1.2/15=80KB/S，系统对传输带宽的要求为640kbps。

第5章容灾系统特点和优点

在容灾项目中，Quest SharePlex for Oracle的数据库复制解决方案具有以下几方面的技术优势。

5.1 支持异构环境

源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。同时，也能够支持不同类型的磁盘阵列（包括SAN）。这不仅能够满足目前异构环境，还能适应未来的扩展需求。很多复制方案的软件产品也宣称能够支持多种主机、操作系统、磁盘阵列，但是他们实际上还是要求主中心和灾备中心的设备是同一类型的。而Share Plex 完全满足主备中心的异构。这样，系统建设是可以选择多种产品参与竞标，大大降低硬件投资，随着公司规模的不断扩大，在硬件升级时，新旧硬件产品可以随意调换，不受限制。

5.2 目标数据可访问

SharePlex独特的实现机制使用户可以对目标系统进行查询操作，因此，可以作为报表查询、统计分析等系统的数据源，减轻源系统的压力，使投资变为可用，而不是单存的冷备闲置。目标数据可访问能够提高容灾系统的投资回报，增加容灾系统的利用价值。同时，目标数据的在线使用实际上是对数据的一个长期在线使用，保障数据的准确性，从而避免容灾系统长期冷备，数据错误而无人发现的情况，能够确保容灾系统在灾难发生时被有效接管，进行数据恢复。

5.3 保证事务的一致性

和其它解决方案不同，SharePlex是一个数据库级的软件解决方案，能够保证每个数据库事务在主备机器之间的一致性。基于智能存储或者卷管理的复制方案是在存储或者操作系统等底层进行数据复制，分为异步和同步两种。同步方案由于较大增加了主系统响应时间，影响主系统的运行，因此不可取；而异步方案由于不能将一系列相关数据库操作作为一个完整的事务提交，而是分为一系列IO操作分别复制，这样，在灾难发生时极有可能这些IO操作只复制了一部分，从而丧失了数据库的一致性，导致复制数据库不能打开，同样也不可取。

5.4 建立复制环境所需要工作量少

SharePlex不需要对硬件、软件、磁盘卷的划分进行任何额外的操作。减少了建立容灾环境对系统结构和应用所作的修改工作。基于智能存储或者卷管理的复制方案需要对空间进行从新划分，以后系统整合时也需要重复同样工作，工作量大且复杂。

5.5 不影响源系统性能

SharePlex for Oracle作为一个独立于数据库和应用的软件解决方案，不会影响源系统的运行。它独特的技术优势使得它对源系统的资源占用很小，对网络资源占用很少。从技术上保障了主中心业务系统的性能和高可用性不会因为容灾中心的建立而受到很大的影响。

5.6 灵活性和扩展性强

SharePlex for Oracle提供多种配置方案，包括单向复制、双向复制、数据集中、数据分布等等。可以很好地满足系统的扩充性需求，充分保护投资。

SharePlex的复制解决方案对应用的扩容没有任何影响。使用SharePlex，源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。同时，也能够支持不同类型的磁盘阵列（包括SAN）。这不仅能够满足目前异构环境，还能适应未来的扩展需求。随着公司规模的不断扩大，在硬件升级时，新旧硬件产品可以随意调换，不受限制。

5.7 优秀的售后服务

对SharePlex for Oracle用户，Quest提供真正意义上的7*24服务。Quest 是为数不多的拥有完善的全球支持体系的公司，其客户服务中心为包括中国在内的全球用户所开放，可以及时处理在产品使用过程中遇到的问题。

第6章容灾系统集成解决方案

SharePlex for Oracle可以自己作为容灾解决方案满足关键业务系统的灾备需求，也可以和其他解决方案集成，提供更好地高可用和容灾功能。

6.1 和基于存储复制技术方案的集成

Quest SharePlex for Oracle和存储复制技术集成可以提供最好的Oracle数据库灾难恢复和负载分担解决方案。该方案可以保证应用在逻辑块冲突、偶然的数据库对象删除错误和本地磁盘损坏等情况下继续运行。同时，可以将OLTP与DSS应用分开运行，以提高应用的整体性能。

下面，以EMC SRDF 和TimeFinder为例说明集成解决方案的优势。

集成方案包括运行于源和目标系统中的Symmetrix磁盘驱动器，在这些磁盘间的EMC的SRDF，一个通过EMC的TimeFinder创建的“第三镜像”，由Quest Software的SharePlex For Oracle维护“第三镜像”的存取和实时更新。主要的管理软件包括：

（1）EMC SRDF：提供带有Symmetrix™磁盘驱动的灾难恢复解决方案。这些磁盘在生产机器上运行，数据的拷贝由带有SRDF™的远程磁盘镜像负责维护。完成从源系统到目标系统的整个环境的磁盘级别的复制。在同步模式下，目标系统是生产机器的精确备份。如果生产服务器出现故障，镜像的磁盘仅仅需要被Mount，使应用可以在完全相同的数据基础上运行。

在正常状态，EMC SRDF复制的目标数据库无法被访问。灾难恢复时，目标系统经过数据库恢复才能够被用户所访问，需要一定的接管时间，同时，由于数据库长期无法访问，可能会出现一些故障导致真正需要时数据库无法启动的状态。

（2）EMC Time Finder：创建一个Oracle数据库作为“第三镜像”。TimeFinder可以阶段性地进行刷新，建立一个和刷新点一致的数据库镜像。通过将第三镜像启动，数据库可以处于被访问状态。但是，由于刷新工作不可能时刻进行，第三镜像只能用于“非生产活动“，如用作测试系统或者对实时性要求不是很高的查询。

（3）Quest SharePlex For Oracle：提供了一个逻辑复制解决方案，将源系统的数据实时复制到由EMC Time Finder软件创建的第三镜像中。由于拥有生产系统实时、不间断的数据拷贝，可以将很多查询操作、数据分析工作移植到第三镜像，从而降低了生产系统的应用负载，变不可用的容灾系统为可用，增加投资回报！同时，SharePlex提供更高级别的容灾保护。对硬件复制不能够提供Oracle数据块损坏和人为错误提供保护。

通过和硬件解决方案集成，SharePlex for Oracle为以数据库为核心的业务系统提供极大的价值，主要表现在：

提供实时更新的、可访问的目标数据库

容灾数据库的在线使用能够提高容灾系统的投资回报，增加容灾系统的利用价值。使投资变为可用，而不是单存的冷备闲置。灾备数据库可以在以下场合：

运行随机查询和报表操作，一方面可以减轻主系统的读取压力，另一方面可以减少用户直接访问生产系统引起的安全性问题

将灾备系统作为数据仓库的数据源

在需要时启用灾备系统作为测试开发环境

提供更高级别的冗灾保护

SharePlex提供逻辑级别的数据复制，和EMC基于物理级别的复制互相补充，提供更高级别的数据保护，避免灾备风险。

减少灾难恢复时间：因为SharePlex For Oracle维护了一个可用的备用实例，如果源系统发生灾难，应用可以立即切换到该备用实例，直到应用可以在被SRDF维护的灾难恢复拷贝中启动。通过这种方法可以有效地减少停机时间。

快速的、没有停机时间的移植

SharePlex可以在不同的Oracle版本间进行复制。当你需要更新Oracle版本时，可以通过复制数据库完成升级。

SharePlex for Oracle独特的队列机制可以有效地减少升级过程中的停机时间，在升级过程中，将生产系统的数据变化存储到队列中，等升级完成后再进行数据加载，可以将整个升级过程的停机时间从几天、几个小时减少到几时分钟。

减少升级风险：SharePlex for Oracle可以建立从高版本环境到低版本环境的数据复制。当应用系统在高版本数据库环境中运行出现问题时，可以非常容易地将应用迁移回原有系统。一旦升级数据库被充分测试，你可以使用EMC的快速刷新功能升级生产应用到新的数据库版本。

使用上述解决方案，复制非常容易初始化。EMC的SRDF和TimeFinder可以创建一个最初的复制实例，由SharePlex For Oracle负责实例间的复制。SharePlex For Oracle可以在同一系统中的不同实例间进行复制，也可以在局域或广域范围内进行复制。SharePlex For Oracle可以被灵活地配置，完成从一个系统向多个系统、从多个系统向一个系统、从系统A向系统B再从系统B向系统C进行的复制。

6.2 和Cluster技术集成

SharePlex for Oracle可以和各种Cluster技术集成，建立起包括本地失败接管和异地数据保护在内的完整的高可用解决方案。在这种配置下。高可用及容灾系统涉及到三台主要的服务器：

ü 主中心：主节点(Primary Node)

ü 主中心：后备节点(Adoptive Node)

ü 灾备中心：灾备节点(Secondary Node)

整个高可用及容灾系统运行过程中具有以下几种状态：

1．正常状态

ü 业务系统运行在主中心，包括数据库实例、有关的文件、数据库数据、应用软件。主节点对外提供服务。

ü Cluster软件对主中心的两台服务器的主机情况、数据库服务、应用软件进行实时监控，准备单点失败时通过Cluster系统进行接管。

2．主中心后备节点接管状态

ü 当主中心的主节点单点失败时，Cluster进行本地切换，将主节点的数据库服务、应用软件、SharePlex数据复制服务切换到本地后备节点。后备节点提供对外服务。

ü Cluster软件对主中心的两台服务器的主机情况、数据库服务、应用软件进行实时监控，准备单点失败时通过Cluster系统进行接管。

3．灾备中心接管状态

ü 当灾难发生时，主中心的数据库服务、应用软件切换到灾备中心的灾备节点。灾备节点对外提供服务。

ü 对主中心的数据库和应用系统进行恢复。

第7章产品到货和验收

Shareplex for Oracle产品到货后，由***公司或其合作伙伴进行产品的安装和调试。保证产品在生产环境的正常运行。产品验收将由最终客户和***公司或其合作伙伴共同进行，确认产品的所有性能指标达到技术规范书的要求，验收内容如下：

1. 选择两台Oracle服务器作为复制的源服务器和目标服务器；在这两台服务器上安装Shareplex产品；

2. 在这两台服务器上运行Ora_setup对数据库进行相应的配置；

3. 在两台服务器上启动Shareplex进程，运行Sp_ctrl命令查看Shareplex的Sp_cop进程是否正常运行；

4. 在源服务器端编辑Shareplex config文件，将表splex.demo_src添加到config文件中，Shareplex会将源服务器splex.demo_src表中的数据复制到目标服务器的splex.demo_dest表中；

5. 确认源服务器的表splex.demo_src和目标服务器的表splex.demo_dest的记录数均为空；

6. 在源服务器端激活config文件；

7. 在源服务器端对splex.demo_src表进行插入操作；

8. 在源服务器端运行Sqlplus在splex.demo_src表中插入一条数据并提交：

9. Sqlplus>insert into splex.demo_src values (‘1’,’test’,’0001’);

10. Sqlplus>commit;

11. 在目标服务器端运行Sqlplus查看splex.demo_dest表的内容，该表的数据和源服务器splex.demo_src表的数据一致。

当上述功能满足时，确认Shareplex产品安装成功并能正常运行。

第8章培训

SharePlex for Oracle标准培训时间为3天，培训地点可以安排在用户现场、***公司北京办事处。培训内容如下：

ü SharePlex Reconcile

ü SharePlex实用程序

ü SharePlex故障检查

ü 获得SharePlex 技术支持

为保证培训质量，对参加培训的学员提出如下要求：

ü 了解UNIX操作系统

ü 了解Oracle数据库

ü 从事或将要从事SharePlex的日常管理工作

第9章技术服务、支持及保修

为保证合同产品的正常运行，***天地电脑技术服务（北京）有限公司（以下称***公司）提供如下的技术支持服务。

9.1 技术支持和维护服务内容

9.1.1 产品升级和维护

***公司将负责技术支持和维护服务期内合同产品的免费升级。

9.1.2 标准技术支持

***公司负责提供技术支持和维护服务期内合同产品的标准技术支持。在正常工作时间内（周一至周五，早9：00至晚6：00，节假日除外），客户可以通过电话、电子邮件、传真等多种手段联系***公司技术支持中心，将使用过程中遇到的产品问题报告给技术支持中心。所有电话、电子邮件、传真都将被记录备案，***公司的技术人员将跟踪问题解决的全过程。

9.1.2.1 电话热线支持

***公司电话技术支持工程师随时接听并回答客户的各种技术问题。通过电话热线支持，工程师将会尽可能在线上解决客户的问题，对于无法立即解决的问题，工程师将记录这些问题并尽快寻求解答。一般的电话支持过程如下：

用户支持电话：010－68011933（周一至周五，早9：00至晚6：00，节假日除外）。

9.1.2.2 E-mail 支持

客户在使用合同产品中遇到的任何问题，都可以发电子邮件给***公司，***公司的技术支持人员会及时响应客户的请求，通过电子邮件和电话和客户进行联系，跟踪并解决相关问题。

电子邮件地址：quest@eglobalchina.com

9.1.2.3 支持状况跟踪

为了准确了解用户的需求、实际应用中所面临的问题及***公司对用户的服务状况，***公司将通过电话方式定期访问用户，以便及时发现问题、适时调整服务内容，从而更好地做好服务工作。

9.1.3 7*24技术服务

ü ***公司提供的7*24服务只被用于处理关键问题，如严重影响客户的生产环境，软件无法使用等等。所有一般性的问题只在正常工作时间受理。

ü 寻求24X7技术服务，可以直接拨打***公司技术支持人员的联系电话，立即得到相关的技术支持。在问题无法解决的情况下，***公司的技术人员会协助联系Quest技术支持中心，获得相应的技术支持。

ü 客户必须提供能够拨号到安装授权软件系统的方法，以便***公司和Quest公司提供快速的服务响应。在尽可能保障生产环境不受影响的情况下，***公司和Quest公司会采用合理的方法解决问题，这可能包括一些极端的情况，如从授权系统中禁用或去除Quest软件。

9.1.4 WWW技术服务支持

客户可以通过Web 直接访问Quest Software的技术支持中心，Quest Support Link， www.quest.com/support。通过Support Link客户可以建立技术请求，检查技术请求的状态，增加注释，查找知识库、访问FAQ等等。

9.2 问题提升和响应时间

***公司记录跟踪本项目实施中提出的产品技术问题，并根据情况划分严重级别，作出相应响应。严重级别如下：

优先级1(L1)：软件产品不能工作，严重影响生产环境；

优先级2(L2)：软件产品能够工作，问题不是很关键，客户无法自行解决；

优先级3(L3)：问题很小，客户可以自行解决；

优先级4(L4)：用户对产品改进的问题；

对于L1类问题，正常工作时间技术支持响应时间为12小时，节假日为24小时。正常工作时间和Quest技术中心联系的响应时间为24小时，节假日为48小时。

对于L2、L3、L4类问题，正常工作时间的技术支持响应时间为24小时。

9.3 技术支持资源

技术支持和维护服务由由***公司技术支持服务中心和Quest技术支持服务中心共同完成。在整个技术支持过程由***公司进行协调处理。

ü ***公司的本地化支持服务

***公司拥有一支受过良好培训、富有丰富经验的技术支持队伍，确保有能力为客户提供最为快捷的支持。***公司的技术人员来自国内主要的数据库供应商，具备多年数据库开发、维护、性能优化和项目管理经验，成功地使用Quest产品为湖南电信、北京电信实施了数据库管理顾问服务，具备强大的技术实力。

ü Quest公司技术支持服务中心

Quest Software 技术支持中心以为客户提供优质的服务为目标。它在美国、英国、加拿大建立三个技术支持中心，面向全球的Quest客户提供技术支持服务。技术中心的人员来自各个专业领域，包括系统管理员、DBA、应用开发人员等等。完善的服务体系和强大的支持能力为Quest产品的有效使用提供了强有利的保障。

在技术支持过程中，***公司和Quest公司的各种技术支持资源相互配合，力求为客户提供多元化的技术支持，保障客户对技术支持的满意度。

第10章公司介绍

1.1. 关于Quest Software

Quest Software（http://www.quest.com）是一家致力于提供保证信息系统和应用程序高性能及高可用性的公司。其产品专业化强，设计细腻，易于使用，被全世界广大用户所使用，在同类产品中具有绝对领先的技术和市场优势。正因为Quest产品的优良性能，Quest Software从公司创立开始，每个季度都盈利，公司发展相当稳健。在针对Oracle数据库管理方面，还没有任何其他公司的产品在功能上、性能上和产品的易用性上和Quest Software的上述产品相媲美。

Quest Software, Inc. (NASDAQ: QSFT) 是业界领先的应用管理解决方案供应商。致力于通过改善企业关键应用的性能和可用性，降低其运行成本，帮助 IT 专业人员高效率地完成关键业务数据和数据库的管理工作。

Quest Software成立于1987年，总部位于加州Irvine，全球员工总数超过2000名，产品用户达到120000多个。

Quest Software的全线产品不仅可以管理包括Oracle,、IBM 和Microsoft在内的数据库应用，也为包括Oracle E-Business Suite,、Siebel eBusiness Applications、mySAP.com、Microsoft Exchange 及 PeopleSoft等企业级应用系统提供了最佳的管理方案。

Quest产品专业化强，设计细腻，易于使用，被全世界广大用户所使用，在同类产品中具有绝对领先的技术和市场优势。相关产品系列包括：

ü 应用监控解决方案，包括系统、数据库和应用监控。

ü 数据库管理解决方案。

ü Microsoft解决方案。

Quest在中国拥有了大量的客户，其中包括北京电信,哈尔滨电信，湖南电信，湖北电信、大唐电信等一大批企业级电信用户。而且以其产品的适用性和高品质博得了用户的赞誉。其主要客户包括：

电信行业	制造行业
新疆移动BOSS系统浙江移动BOSS系统福建移动BOSS系统北京电信长途计费系统天津电信计费系统浙江电信九七系统湖北电信计费系统湖南电信计费系统哈尔滨电信九七系统广东省数据局大唐电信	Motorola公司长江电器北方工业公司光明乳业上海通用汽车公司东方海陆集装箱码头有限公司上海外高桥集装箱有限公司大连实德集团
政府机关	金融、保险行业
北京地税国家统计局中国国际贸易促进会中国互联网信息中心	博时基金东方资产安联大众人寿保险有限公司新华保险有限公司

1.2. 关于eGlobal Technology

eGlobal Technology Services (***天地) 总部位于新加坡，是亚太知名的IT解决方案及专业技术服务供应商，致力于帮助本地企业成功实施国际领先的产品和技术解决方案，提高其在国内和国际市场的商业竞争力。***天地的业务遍及澳大利亚、中国、印度尼西亚、韩国、马来西亚、新西兰、新加坡、泰国、香港及台湾等国家与地区。

***天地电脑技术服务(北京)有限公司是eGlobal Technology Services在华注册的独资企业，与***天地亚太区总部和其它亚洲分支机构互相配合，共同满足国内用户对高质量、本地化技术、产品和服务的特殊需要。

***天地的员工大多来自业界知名IT企业，在商业智能、客户关系管理和IT性能管理等方面具有雄厚技术实力。 "Global Technology, Local Delivery" 是eGlobal的企业理念，也是一种特殊的业务模式，能够帮助本地企业引进和实施世界领先的产品、技术和服务，实现理想的客户满意度。

eGlobal作为亚太本土在长起来的专业技术公司，有着多年帮助本地企业实施国际先进产品、技术和服务的经验；面对发现这样问题，eGlobal确立了以全球领先技术和本地化服务(Global Technology, Local Delivery)为中心的商业理念，集中来国际厂商和eGlobal的自身技术力量，着力服务本土企业。eGlobal的业务模式，很好地解决了长期以来困扰亚太用户的主要问题，使他们不必在采用先进技术时瞻前顾后地思考本地实施的风险，在产品技术和本地支持这种两难的选择之间摇摆不定。随着eGlobal业务的开展，越来越多的本地企业开始从这种服务模式中受益。

eGlobal与全球领先的供应商结成了合作伙伴，将他们的一流产品与技术提供给亚太用户。同时，***还充分发挥了本地资源的优势，通过高水平的专业队伍，为用户提供项目实施、支持和咨询服务。用户得到的，不是某个产品在当地的系统集成商或代理商的服务，而是由eGlobal直接代表的供应商服务，以及良好的质量保证和管理体系服务。另外，eGlobal各国公司及其亚太总部的技术力量还密切合作，共同满足用户在具体实施中的特定需求。

第11章 SharePlex for Oracle成功案例

11.1 澳大利亚NEMMCO公司利用SharePlex实现应用系统失败接管

澳大利亚国家电力市场管理公司（简称NEMMCO）是一家从事电力经纪交易的公司。应用SharePlex高可用性解决方案避免了总值80亿元市场交易活动的中断，保证了业务交易的连续性。通过与其它复制技术进行对比测试，SharePlex显示出了优越的性能，使NEMMCO公司的失败接管时间由原来的3小时以上降低为不到30分钟，而且不损失任何数据。

业务挑战

NEMMCO公司整个交易管理系统包含12个大型生产数据库，同时运行60个应用。每个数据库存储130G数据，每小时产生250M Redo Log日志。

这些数据库用于向公司内部和外部客户发布有关电力价格、市场统计数据、电力派送、报表、结算和计费等方面的信息。

如果系统的停机时间超过30分钟，NEMMCO公司就不得不中断整个交易活动。一旦系统恢复，公司需要赔偿客户在停机期间所收遭受到的损失。

为了确保管理系统的安全性，NEMMCO公司也需要改变他们整个生产环境的地址，这就要求有一种灵活的解决方案能够实现多场点和多服务器之间复杂的复制。

“由于业务非常关键，我们需要一种功能强大和可靠的复制工具来帮助完成多场点之间大量数据的移动，并且延迟时间少于30秒。” NEMMCO公司数据库开发组经理Kris Downey说。

由于目前的失败接管方案需要3小时以上的时间，因此NEMMCO公司需要寻求其它方案使得不同场点间的失败接管和维护工作在30分钟之内完成，以避免中断交易活动。

Quest解决方案

NEMMCO公司非常熟悉SharePlex解决方案，在此之前已经使用了三年SharePlex用于维护其报表数据库实例。NEMMCO公司同时对Oracle的Advanced Replication （OAR）和SharePlex进行评测。在评测过程中发现SharePlex能够满足性能要求，而Oracle的解决方案在其Oracle7.3.4数据库上不稳定，难于维护并且不能满足数据同步要求。

NEMMCO公司将SharePlex的多种复制策略相结合来管理电力交易中的数据。利用SharePlex实现了不同平台、不同Oracle数据库版本和操作系统之间的复制，同时也利用SharePlex的复制功能实现不同场点之间的灾难恢复。

SharePlex每天在不同场点之间的主数据库之间复制6G Redo Log数据，在报表和结算计费数据库间复制3G数据。NEMMCO公司利用SharePlex来维护一个报表数据库实例，从而减轻了对主数据库资源的消耗。

应用SharePlex不久，NEMMCO公司的报表数据库服务器发生故障，导致其上运行的SharePlex进程被停止。在发现和更正错误后，主数据库上SharePlex已经保存了48小时的日志数据。但报表数据库上的SharePlex被重新启动后，只用了不到两小时时间就将保存的日志处理完毕，又利用5分钟实现两个数据库的同步。NEMMCO公司也经历过其它类似的故障，如系统停机20个小时，但利用SharePlex在30分钟内就完成了恢复工作。

“SharePlex可以快速实现数据同步，比其它方案都要快，而在从前，如果发生故障，要想把系统重新同步是件非常困难的事情。Oracle的复制方案无法满足性能要求，但SharePlex可很好地实现我们的管理目标。” Downey说。

NEMMCO已经将SharePlex应用于极其复杂的失败接管环境中。接管过程由80步组成，包括确保应用正常执行、文件服务器保持最新数据、按特定顺序启动和停止应用程序以及接管内部和外部网络访问等。

“一旦失败接管过程结束，即应用在备用场点启动和运行，SharePlex就可快速和准确地在不同场点之间以及向其它数据库复制数据。” Downey说。

收益及投资回报

SharePlex非常可靠和灵活，可以满足公司关键业务的需求。“如果需要为报表数据库实例实现有效和高速的复制，或者在多场点之间实现高可用性和高效的失败接管方案，建议你采用SharePlex。” Downey说。

SharePlex可以确保NEMMCO公司实现其30分钟内完成失败接管的目标。利用SharePlex，目标系统和源系统间的延迟在2秒到10秒之间，大大低于其30秒的目标。SharePlex在复制过程中也只消耗很小的CPU资源，不影响系统和应用的性能。

SharePlex帮助NEMMCO公司确保当一个场点失效时，其它场点能够快速地进行接管，用户的交易活动不受到影响，整个市场的业务也无须中断。

“SharePlex允许我们重新定位结算和计费处理到其它的服务器上。这使资源得到了合理的利用，防止了结算和计费处理冲击正常的交易业务处理。” Downey说。

“利用SharePlex之前，每一次有计划或意外停机所需要的恢复时间都超过3个小时，从而不得不中断市场交易。” Downey谈到。“如果我们的系统停机时间超过30分钟，我们就不得不中断整个交易活动，而且需要赔偿客户在停机期间所遭受到的损失。我们选择SharePlex是因为它是可靠的、灵活的解决方案。更为重要的是，它可以满足我们少于30分种失败接管时间这一需求。对于这一需求的满足意味着公司将节省大量开支。”

关于NEMMCO公司

NEMMCO公司成立于1996年，由澳大利亚首都和新南威尔士、昆士兰、南澳大利亚及维多利亚地方政府共同创建，负责管理和运营世界上最大的国家电力交易市场。通过在布里斯班、悉尼和墨尔本设立办公室，NEMMCO公司的目标是为国家电力交易市场的有效运营提供基础平台保障，同时也负责维护电力系统安全和协调电力系统计划和电力传输。

11.2 加拿大太平洋铁路公司利用SharePlex实现系统高可用性

加拿大太平洋铁路公司（CPR）是北美地区最大的铁路公司之一，利用Shareplex确保系统的高可用性和完成系统维护及升级工作，成功地将关键业务系统的平均停机时间从原来的每月超过12个小时缩短到不超过20分钟，从而能够为用户提供良好的服务并节省了数百万元的开销。

业务挑战

CPR是一家全天候运营的铁路公司，为用户提供24x7的服务，因此为了进行系统升级而将铁路业务系统停机20个小时或更多时间是不现实的。目前其业务系统的正常运转是由一个集成的IT系统来实现的，在此系统中运行着35至40个自行开发的应用。CPR的IT管理人员需要确保最关键系统--企业信息中心--的高可用性，此系统收集和存储有关铁路车辆运转、车辆调度、车辆预定、运输计划、员工调度及客户信息等最关键的企业信息。目前此系统采用两台IBM服务器，为实现操作系统级的自动接管，服务器上配置有IBM的HACMP，每台服务器上分别安装相对独立、结构配置相同的Oracle数据库。数据库存有150GB数据和40GB日志，每天处理超过3000万笔事务。由于经常需要进行重组表、重构数据文件、实施新系统和完成升级，因此CPR决定寻求一种有效的解决方案来帮助其实现消除或大大减少有计划和意外停机时间，提升整个系统可用性和性能的管理目标。

Quest解决方案

CPR评测了多种高可用性解决方案，包括Quest的SharePlex、Oracle的Parallel Server和Symmetrical Replication以及HP、Sun、IBM 和Compaq等公司提供的解决方案。除了Quest的SharePlex，其它解决方案要么消耗太多的CPU资源、要么管理过于复杂、要么需要较多的停机时间、要么无法与CPR的现有系统进行有机集成而都不能满足需求。SharePlex优异的性能特色，如实时复制、低负载、跨数据库和操作系统平台等能够很好地满足CPR的管理需求。

CPR的IT管理人员对SharePlex评价到：“安装和配置SharePlex所需要的时间很少，我们可以先在一台服务器上实施SharePlex，然后逐步扩展到其它服务器上，整个实施过程对系统的影响很小；而且更为方便的是，实施SharePlex，我们根本无需修改我们的应用。”

CPR利用SharePlex完成每周一次的源系统和目标系统之间的切换，从而可以实现对目标系统所有的应用升级、版本维护、表和字段修改以及增加对象等管理工作。

收益及投资回报

应用SharePlex之前，CPR每月需要12个小时以上的停机时间来完成系统软件、应用程序和硬件环境的升级工作。而在实施完SharePlex后，系统的维护停机时间降低到每月不到20分钟，很好地满足了系统的高可用性和性能要求。

对于实施SharePlex所取得的效果，IT管理人员感到欢欣鼓舞：“SharePlex的实施和使用效果超过了我们的期望值，也使我们达到和超过了我们所承诺的用户服务等级。从Oracle 7.3.4升级到8.1.3只需要不到5分钟的停机时间，简直是令人不可置信的，这无疑是一笔巨大的投资回报，可以将停机损失降至最低。”

此外，采用SharePlex后，DBA无需再利用晚上、周末或节假日来完成新应用的实施和系统维护工作。而且实施SharePlex后，维护系统的高可用性所需工作量也大为减少，只相当于原来的20%至50%左右。

SharePlex减少了有计划的停机时间，提高了系统的可用性和性能。CPR认为SharePlex已被证明对于一个运行40多个应用的企业来说是非常有效的解决方案。

将关键业务系统的平均停机时间从每月12个小时以上减少到不到20分钟

帮助实现从Oracle7.3.4升级到8.1.3只需不到5分钟的停机时间节省了数百万元停机损失

关于加拿大太平洋铁路公司

加拿大太平洋铁路公司是北美地区第一个跨地域运营的铁路公司，也是加拿大唯一拓展业务到美国东海岸的铁路公司。加拿大太平洋铁路公司一万四千英里的铁路网不仅能为从蒙特利尔到温哥华的加拿大中部地区提供服务，而且也为美国东北部和中西部地区提供服务。由于其铁路网与芝加哥枢纽中心相连接，因而来自东海岸和西海岸物质可直接输送到美国各地。

此外，与其他铁路公司广泛的联盟大大扩展了加拿大太平洋铁路公司的业务范围，使其业务范围拓展到直至墨西哥中部地区。

11.3 Honeywell公司利用SharePlex实现即时更新的报表功能

Honeywell是全球控制系统业内领先的公司，其商业电子系统、航天系统和传感产品部门每天需要四次，每次45分钟的有计划停机时间进行数据刷新工作，从而生成包含最新信息的业务报表。应用SharePlex使其消除了这些有计划的停机时间。同时，也使公司每月月底的财务结算时间由过去的五天减少到三天，而且对800个用户几乎没有任何影响。

业务挑战

Honeywell的商业电子系统、航天系统和传感产品部门创造着控制技术领域年销售超过40亿美元的业绩。Honeywell公司面临的一系列挑战为：实施Oracle财务系统、将原有的200在线用户数扩大到800个、提供即时更新的财务报表而不影响在线业务系统。Craig Sharpe，作为公司IT环境建设项目主管，负责为这些部门解决这些问题。

Honeywell公司的系统环境由HP机群和24个Oracle数据库组成，其中多数Oracle数据库用于OLTP业务。系统运行Oracle财务应用，管理超过6000个表和28G数据。

“我们现有的维护组包括6个数据库管理员，4个系统管理员，负责为200个用户提供支持。但是，我们正在扩展财务系统应用，在其中增加帐务应收、帐务支付和项目审计应用，这将使数据库的用户数增加到800个。” Sharpe说。

为了生成业务报表，维护人员采用了EMC的TimeFinder，每天为数据库作三到四次的镜像操作。每次镜像操作要求45分钟的停机时间，停机时间有时不得不发生在系统使用高峰期，如月底的结算期。而且，财务系统的用户越来越无法忍受有四个小时延迟的信息，这些信息无法满足他们制定及时、准确的财务决策的需求。为了获得即时更新的数据，他们开始要求访问OLTP系统。但是维护组的技术人员认为允许他们访问OLTP系统将带来严重的性能问题。

Quest解决方案

作为一个复制方案，SharePlex可以集成到EMC的TimeFinder环境中。利用SharePlex建设了一个提供即时更新信息的报表数据库实例。

“报表数据的延迟不超过几分钟，对生产系统的开销非常低，几乎察觉不到。” Sharpe说。

实施SharePlex前，维护人员与Quest公司的技术顾问一道根据系统实际情况和需求定制实施方案。“所有的准备工作都预先完成，我们清楚了解实施工作，实施过程几个小时内就完成了，而且无需系统停机。”Sharpe说。

此外，为了提高应用的可用性，维护人员使用了Quest的应用系统管理解决方案，包括Space Manager、SQLab Vision和I/Watch。这些性能优化和监控方案可以使维护人员在用户受到影响之前就预先地监控、诊断和解决影响系统性能和可用性的问题。这些方案可以实现对Oracle实例快速和简便的维护，同时对SharePlex复制方案也是一个充实，从而确保整个系统的稳定性，实现关键业务信息的快速访问。

收益及投资回报

维护人员感受到了实施SharePlex所带来的益处。采用新的ERP系统和SharePlex，每月月底的财务结算时间从五天降低到了三天，用户也无需再经历每天4次，每次45分钟的停机操作。用于生成报表的数据与生产系统数据只相差几分钟或几秒钟，同时OLTP用户也获得了良好的性能。两个小时的实施过程无需停机时间，SharePlex带来了立即的投资回报。而且，SharePlex 几乎不需要时间和精力来维护。“SharePlex非常易于管理，仅需要一个数据库管理员大约5%到10%的时间。”维护人员说。

Sharpe总结他对使用SharePlex的感受时说到：“它非常快速、系统开销很小，而且不占用我们很多时间，但最重要的是我们的客户感到很满意。”

关于Honeywell公司

Honeywell公司始创于1885年，拥有在熔炉温度调控和家用取暖报警设备方面的专利。目前Honeywell公司已经成为家用、建设和工业自动化控制系统以及高新技术、航天和国防工业领域的佼佼者。

Honeywell的先进技术使数百万人获益菲浅，帮助用户提高生产效率和竞争力、增强舒适度和安全性、保护环境和节约能源。

在1999年秋，通过与AlliedSignal公司合并，Honeywell公司将其业务拓展到非常广泛的范围，包括：航天、消费品、电子材料、耐摩材料、家庭和建筑控制、工业控制、橡胶、专业化学品、交通运输和能源系统。

容灾备份异地容灾数据容灾容灾系统数据同步复制采集归档检索集中分发容灾方案异地容灾备份远程容灾容灾技术异地容灾方案oracle容灾容灾方案异地容灾数据容灾容灾是什么容灾系统异地容灾备份oracle容灾容灾备份数据容灾系统异构容灾方案下载EMCSRDF容灾技术和业务连续性服务方案,IBMPPRC,HPBusinessCopy,HDSTrueCopy,VERITASVVR；DSGRealSync,QuestSharePlex等,HDS数据中心容灾解决方案,飞康公司的持续数据保护(CDP)抽取共享升级迁移优化灾难恢复备份恢复数据保护器FalconStorCDP,StoreAge容灾方案,SEPATON容灾解决方案oracle数据库备份oracle自动备份oracle数据备份oracle冷备份oracle备份表证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带oracle备份与恢复oracle定时备份oracle备份命令oracle热备份oracle的备份与恢复oracle如何备份oracle备份还原oracle备份方式oracle逻辑备份oracle9i备份oracle联机备份DSG公司DSGRealSync数据库复制容灾软件抽取共享升级迁移优化灾难恢复备份恢复oracleexp备份oracle备份rmanoracle的备份oracle远程备份oracle的rman备份oracle备份方案oracle备份脚本oracle数据备份语句oracle备份工具oracle增量备份oracle备份技术oracle物理备份oracle冷备份脚本异地容灾备份oracle备份表空间SnapAssure高速备份恢复软件pb备份oracle数据库oracle备份级别oracle容灾备份oracle容灾方案oracle容灾技术招标oracle容灾备份oracle容灾dataguardoracle容灾产品电信级容灾系统建设boss容灾系统分布式数据容灾系统数据同步复制采集归档检索集中分发容灾系统的实现原理数据库容灾系统上海移动boss容灾系统证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带RealMigrates数据库异构平台实时迁移软件建设银行容灾系统异地容灾系统结构pptvvr容灾系统容灾系统级异地容灾方案veritas异地容灾方案远程容灾方案vvr容灾方案iscsi容灾方案oracle容灾方案应用级容灾方案数据同步复制采集归档检索集中分发数据容灾方案远程异地容灾方案电信容灾方案数据备份方案双机热备份方案数据库备份方案服务器备份方案oracle备份方案oracle数据库备份方案异地备份方案异地容灾备份veritas备份方案doc磁带机备份方案企业数据备份方案案企业数据备份方案北京天津河北山西内蒙辽宁吉林黑龙江上海江苏浙江安徽福建江西山东河南湖北湖南广东广西海南四川重庆贵州云南西藏陕西甘肃青海宁夏新疆大连厦门青岛苏州应急平台容灾中心查询平台OLTP VS OLAP数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用

SharePlex for Oracle应用系统高可用和容灾方案相关推荐

世界领先！详解蚂蚁金服自研数据库OceanBase的高可用及容灾方案
小蚂蚁说: 关于蚂蚁金服自研的金融级分布式关系型数据库OceanBase的故事相信大家已经不再陌生了(新来的同学可以移步<厉害了,蚂蚁金服!创造了中国自己的数据库OceanBase>了解更 ...
支付宝的高可用与容灾架构演进
http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=402390133&idx=1&sn=395cf6e500ea912f ...
《支付宝的高可用与容灾架构演进》读后感
本篇文章主要介绍了支付宝高可用和容灾能力建设的解决思路,高可用性指的是一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性.容灾能力一般特指面对自然灾害时的处理与恢复能力.在架构设计中, ...
如何构建故障与危机的处理能力？《高可用及容灾架构体系化建设》下篇
如何建设全面的高可用及容灾架构体系,是一个涉及到广泛领域的话题,将分成上.下两篇呈现给读者.本文将在上篇的架构基础上,构建完整的故障与危机的处理能力,同时通过持续运营与组织保障机制的协同,打造出全面的 ...
怎样建设稳定性基础架构？《高可用及容灾架构体系化建设》上篇
如何建设全面的高可用及容灾架构体系,是一个涉及到广泛领域的话题,将分成上.下两篇呈现给读者.本文讨论的架构体系,解耦具体产品实现,尽量只从架构原理出发,从构建一个韧性的应用基础架构内核开始,到增强应用 ...
SequoiaDB 巨杉数据库学习-高可用与容灾
高可用是指数据库的持久性.冗余性和自动故障转移能力.容灾是指在相隔较远的异地,搭建一个完整的集群环境,当一个地方发生灾难停止工作时,可以切换到另一处,使得系统可以正常提供服务. 高可用高可用是指通过 ...
【数据库】从操作上描述 OceanBase 的高可用与容灾
目录闪回回收站闪回回收对象 Restore Point 闪回查询多数据库版本备份恢复管理概述物理备份架构物理恢复架构备份备份的数据基本概念数据校验恢复数据执行全量恢复场景示例 ...
rocketmq 如何保证高可用_RocketMq容灾、高可用方案
一.实现分布式集群多副本的三种方式 1.1 M/S模式即Master/Slaver模式.该模式在过去使用的最多,RocketMq之前也是使用这样的主从模式来实现的.主从模式分为同步模式和异步模式,区 ...
玩转ECS第6讲 | 弹性计算Region化部署和跨可用区容灾介绍
简介:本次分享由阿里云弹性计算架构负责人李钟(谢顿)为大家介绍阿里云region化部署和跨可用区容灾的实践经验,说明多Region部署场景中使用阿里云弹性计算的最佳实践,并结合弹性计算的实践经验探讨如 ...

SharePlex for Oracle应用系统高可用和容灾方案

第1章 前言

第2章 高可用容灾方案设计

4.2.4 容灾中心的数据恢复到主中心

9.1.2.3 支持状况跟踪

9.1.3 7*24技术服务

9.1.4 WWW技术服务支持

9.2 问题提升和响应时间

9.3 技术支持资源

SharePlex for Oracle应用系统高可用和容灾方案相关推荐

最新文章

热门文章

第1章前言

第2章高可用容灾方案设计