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) 数据集中和广播 </