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

 

第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.1.1    计划外的系统停机

计划外的系统停机指由于应用系统故障导致的系统不可用。减少计划外的停机时间是应用系统设计人员和管理人员面临的主要任务，虽然每个业务系统都在硬件、软件和人员方面投入很多，但每年计划外的停机时间还是不可避免的发生，造成了很多不可避免的经济损失。一般来说，计划外的系统停机主要是由于以下原因引起的。

1. 人为错误。如用户具有过多的权限，从而可以访问没有被授权的一些数据。或者数据库管理人员过度劳累导致的错误。

2. 硬件 / 软件出错。硬件和软件失败是不可避免的现象，而且随着数据库系统使用年限的增加而变得更加脆弱。通常由于硬件 / 软件出错所引起的故障包括应用程序出错、数据库出错、操作系统故障，如操作系统死机等以及硬件故障，如硬盘或网卡损坏等。

3. 环境失败。环境失败指由于外部环境改变导致系统不可用或无法有效地进行数据库管理。如断电，工人罢工等等。

2.1.2    计划内的维护操作

系统操作人员经常提到的一个术语就是“维护”。大多数维护操作会影响到系统的可用性和性能。 由于进行主动系统维护所引起的停机时间被称为 计划内停机时间。对于每个数据库应用来说，每年或每月都需要一定的计划内停机时间，因为停机时间可以控制，停机操作对系统的影响也可以预先通知到用户，因而计划内停机时间虽然发生频繁，对系统的影响可以控制在一定范围。

2.1.3    灾难恢复

对于高可用需求的应用系统来说，自然灾害与人为灾害始终存在。自然原因引起的灾难包括地震、洪水、火灾、飓风、恐怖活动、 战争、暴乱 活动等，人为因素导致的数据库不可用包括故意破坏。这些灾难发生的概率非常低，但是如果一旦发生，对严重依赖于数据的企业是致命的打击，甚至导致企业无法继续运营。

在灾难发生的情况下，数据恢复成为高可用性管理的首要任务，数据备份、特别是异地数据备份是成功实现灾难恢复的核心。企业需要在保证业务数据恢复的情况下保持业务系统的连续性。

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介绍

目前，很多厂家都提供容灾保护的产品，主要包括基于存储、逻辑卷、主机、数据库物理方式和数据库逻辑方式的各种复制技术。根据复制层面的不同，实现的技术以及容灾效果各不相同。 Quest Software 的 SharePlex for Oracle 通过数据库逻辑层的复制技术，可以方便地实现基于 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

3)        oratab file

4)        /etc/services

5)        /etc/system

6)        /etc/group

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 基于物理级别的复制互相补充，提供更高级别的数据保护，避免灾备风险。

提供更多的灾难恢复保护：和所有的镜像解决一样， SRDF 无法处理块冲突和人为的错误操作，如删除某一有用的表等等。因为 SharePlex 维护的是一个逻辑的数据库复制，它为块冲突 ( 如 Oracle Error 600) 和意外的 DDL 错误提供了保护。

减少灾难恢复时间：因为 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 系统进行接管。

ü         主中心的主节点将相关数据通过 SharePlex for Oracle 实时复制到灾备中心的灾备节点。

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

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

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

ü         主中心的后备节点将相关数据通过 SharePlex for Oracle 实时复制到灾备中心的灾备节点。

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 介绍

ü         术语

ü         进程

ü         结构

ü         Shareplex 产品安装

ü         SharePlex 实施的前期准备

ü         配置 SharePlex

ü         SharePlex 控制和监控

ü         日常维护操作

ü         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 支持

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

电子邮件地址：[email protected]

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 的解决方案在其 Oracle 7.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 分钟

帮助实现从 Oracle 7.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数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用

容灾备份异地容灾数据容灾容灾系统数据同步复制采集归档检索集中分发容灾方案异地容灾备份远程容灾容灾技术异地容灾方案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数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用