在
企业信息化进程不断加快的今天，保持业务的连续性是企业用户进行数据存储时必须考虑的重要方面。灾难的出现可能导致生产停顿、客户满意度降低，减少企业的
竞争力。如何安全、可靠、完整地保存数据，实现系统的灾难恢复是市场竞争的需要，更是进一步提高服务水平和改善服务质量、提升业务支撑能力的重要技术手
段。
“911”事件使大家更加谨慎地审视自己的应用系统。据有关数据表明，接近50%的公司需要关键业务24小时连续运作，但是在这些公司中，有67%的公司没有在其他地方拥有冗余的计算机设备，79%的公司没有后备的关键业务系统，86%的公司没有适当的备份计划和数据恢复计划来保证业务的连续运行。在9月11日纽约世贸中心惨剧发生之后，所有世贸大楼公司的商务资料在瞬间毁于一旦，有些公司由此退出了市场的角逐。而一些公司却得益于自己的灾备系统，从而保住了公司依赖生存和发展的资本-数据。
容灾系统的建设包括两个重要因素，即业务系统的连续性和业务数据的可恢复性。在“911”事件以前，很多企业的高可用性方案主要从应用系统的连续性考虑。其中最普遍采用的是通过高可用集群双机系统(Cluster或HA)对
业务应用提供保护，在一台服务器的软硬件发生故障时，将整个业务切换到后备服务器上。该方法很大程度上避免了服务器的单点故障，提高了整个业务系统的可用
性。但从整个应用系统的角度，高可用集群只能实现一部分的高可用性目标。例如它无法处理存储设备故障，也无法处理计划内的停机时间和容灾恢复。在数据的可
恢复性方面，主要采用的技术是各个层次的备份和恢复机制。但对于海量数据的备份和恢复存在一定的难度，而且备份恢复一般局限于本地，在出现类似”911”的灾难时无法进行有效的恢复。
所
有这些都要求企业重新设计和建立自己的高可用性和容灾系统。对于业务严重依赖于数据的企业来说，此系统必须包括保证应用系统的连续性，并提供有效的数据恢
复机制。应用系统的连续性则应该从最终用户的角度来衡量，以整个系统的停机时间和可接受程度作为评价标准。数据恢复规划则需要以企业IT人员的视角来进行，肩负着在真正灾难发生时维系企业命脉的责任。
目前，很多厂家都提供容灾保护的产品，主要包括基于存储、逻辑卷、主机、数据库物理方式和数据库逻辑方式的各种复制技术。根据复制层面的不同，实现的技术以及容灾效果各不相同。Quest Software的SharePlex for Oracle通过数据库逻辑层的复制技术，可以方便地实现基于Oracle数据库的容灾保护，具有对源系统资源占用少，对网络资源占用少，支持异构环境和不同的复制拓扑，保持事物一致性的特点。在开放异构环境、异地容灾、容灾系统可访问的环境中具有非常大的优势。
通过SharePlex for Oracle，可以帮助企业建立一个全面的、整体的容灾方案，最大限度地保证业务系统的连续性和业务数据的可恢复性。
设计
系统的影响因素
影响应用系统可用性主要有三方面的因素，计划外的系统停机、计划内的维护操作和灾难恢复。
计
划外的系统停机指由于应用系统故障导致的系统不可用。减少计划外的停机时间是应用系统设计人员和管理人员面临的主要任务，虽然每个业务系统都在硬件、软件
和人员方面投入很多，但每年计划外的停机时间还是不可避免的发生，造成了很多不可避免的经济损失。一般来说，计划外的系统停机主要是由于以下原因引起的。
1.人为错误。如用户具有过多的权限，从而可以访问没有被授权的一些数据。或者数据库管理人员过度劳累导致的错误。
2.硬件/软件出错。硬件和软件失败是不可避免的现象，而且随着数据库系统使用年限的增加而变得更加脆弱。通常由于硬件/软件出错所引起的故障包括应用程序出错、数据库出错、操作系统故障，如操作系统死机等以及硬件故障，如硬盘或网卡损坏等。
3.环境失败。环境失败指由于外部环境改变导致系统不可用或无法有效地进行数据库管理。如断电，工人罢工等等。
系统操作人员经常提到的一个术语就是“维护”。大多数维护操作会影响到系统的可用性和性能。由于进行主动系统维护所引起的停机时间被称为计划内停机时间。对于每个数据库应用来说，每年或每月都需要一定的计划内停机时间，因为停机时间可以控制，停机操作对系统的影响也可以预先通知到用户，因而计划内停机时间虽然发生频繁，对系统的影响可以控制在一定范围。
对于高可用需求的应用系统来说，自然灾害与人为灾害始终存在。自然原因引起的灾难包括地震、洪水、火灾、飓风、恐怖活动、战争、暴乱活动等，人为因素导致的数据库不可用包括故意破坏。这些灾难发生的概率非常低，但是如果一旦发生，对严重依赖于数据的企业是致命的打击，甚至导致企业无法继续运营。
在灾难发生的情况下，数据恢复成为高可用性管理的首要任务，数据备份、特别是异地数据备份是成功实现灾难恢复的核心。企业需要在保证业务数据恢复的情况下保持业务系统的连续性。
系统的容灾和高可用方案必须能够应付所有可能引起计算机系统失效的问题。应用系统高可用性和容灾方案需要满足两方面的要求：
1．业务系统的连续性
保持业务系统的连续性，意味着无论是由于硬件，软件或电源的失效都不应中断信息中心的处理工作；实现业务的连续性需要减少或消除计划外停机时间，控制计划外停机时间对系统的影响，在灾难发生时间进行业务系统的快速接管，这些主要通过各个层次的冗余技术实现的。
2．业务数据的可恢复性
业
务数据的可恢复性从本质上来说是业务系统连续性的一个子集。如果数据出现问题而不能恢复，业务系统的连续性无从谈起。因为数据对严重依赖于信息系统的企业
非常重要，数据的可恢复性一直是高可用性系统的一个重点考虑因素。业务数据的可恢复性是通过数据备份和冗余的数据拷贝完成的。数据库复制和硬件复制都是用
于这个环境的一些成熟技术。业务数据的可恢复性主要考虑因素为备份数据的安全性，需要确保在任何情况下，包括容灾发生时备份数据都可以有效地进行恢复。同
时，数据丢失也是一个非常重要的评价指标。
因为要建立整个应用系统的冗余备份，容灾系统是一个非常昂贵的系统，在容灾系统建设时需要考虑以下因素：
（1）容灾距离：
根据灾备中心建设的目的不同，灾备中心的建设需要考虑灾备中心的距离。一般来说，容灾距离有本地和同城、异地三种方式。
异
地容灾方案中，灾备中心和主中心的距离较远，如北京到上海。异地容灾可以有效地防止由于本地灾难发生引起数据损失，但是实施成本很高、为了保障业务系统的
性能一般采用同步数据拷贝方式，这样会存在一定的数据损失，同时将应用系统切换到灾备中心的工作也非常繁琐。一般来说，异地灾备中心建设的主要目的提供业
务数据的恢复能力。
同城容灾方案中，灾备中心和主中心距离在几十公里以内。同城容灾可以有效地提供业务数据的恢复能力以及应用快速接管能力。根据业务系统对数据访问以及数据丢失的需求，数据复制可以采用同步或异步两种方式。
同地容灾指灾备系统和主中心在一个地理位置。一般来说，它可以和现有的其他可用性技术，如Cluster结合，提供更高级别的高可用性。同时，很多同地容灾解决方案提供灾备中心的数据访问能力。
为了有效地进行容灾，很多关键的业务系统建立两个系统，同城灾备中心和异地灾备中心，同城灾备中心由生产系统采用同步方式进行数据复制，异地灾备中心由同城灾备中心采用异步方式进行数据复制。
（2）数据丢失
企
业能忍受的数据丢失和具体处理的业务有关。例如：财务系统的数据很难承受任何损失，而电信营帐系统在灾难发生时可以允许少量的数据丢失。目前，虽然有很多
方案可以做到“零数据丢失“，但企业往往为此支付高昂的费用，生产系统的性能也会受到很大影响。从业务的角度企业能够承受德考虑数据丢失问题可以帮助企业
在容灾方案上做出适合企业自身特点的选择。
（3）应用切换时间
容
灾系统建设的一个重要目的是保障业务系统的连续性。在灾难发生或业务系统出现问题时间，将应用快速地切换到灾备系统可以最大程度地减少系统的停计时间。当
灾难发生，启用灾备中心需要采取一系列的措施。如将网络、电话线路切换到新的地点，启动操作系统、数据库，进行应用程序的切换等等。一般来说，容灾系统的
切换时间应该控制到30分钟以内。
（4）主系统的可恢复性
主系统的可恢复性主要指数据的恢复，将应用切换灾备系统后，业务的连续性得以保持，主系统的恢复时间应该控制在一天到几天之内。数据恢复的关键问题在于数据的可恢复性，以及恢复过程中如何和灾备中心的数据保持一致。
（5）目标系统的可访问性
目
标数据可访问能够提高容灾系统的投资回报，增加容灾系统的利用价值。企业可以将目标系统作为报表查询、统计分析等系统的数据源，减轻源系统的压力，使投资
变为可用，而不是单存的冷备闲置。同时，目标数据的在线使用可以保障数据的准确性，从而避免容灾系统长期冷备，数据错误而无人发现的情况，能够确保容灾系
统在灾难发生时被有效接管，进行数据恢复。
（6）对源系统的影响。灾备中心的建设是对现有系统的扩展和补充，不能因为灾备中心影响当前业务系统的性能，导致系统的可用性降低。
（7）网络资源的使用。网络资源的使用对于容灾系统特别是异地容灾系统非常重要。在网络上传输的数据量大小直接决定数据传输的实时性，同时，网络资源占用会影响灾备中心后期的网络使用费用。
（8）容灾环境的开放性。组成数据库应用系统的环境非常复杂，主机、存储、数据库是容灾环境的三个主要组件，支持开放环境，例如容灾系统支持不同的操作系统和数据库、不同的磁盘阵列、不同的主机系统会有效地适应未来的扩展需求，充分保护投资。
实施成本是在充分评估了上述内容后需要考虑的又一个重要因素。事实上，在建立容灾系统时，一个对业务系统没有任何影响、没有任何数据损失、容灾距离足够远的方案是很难实现的。企业需要了解自己的需求，建立适合自身特点的容灾系统。
利用磁带拷贝进行数据备份和恢复是最常见的传统灾难备份方式。这些磁带拷贝通常都是按天，按周或按月进行组合保存的。
使用这种方式的数据拷贝通常是存储在盘式磁带或盒式磁带上，并存放在远离基本处理系统的某个安全地点。存储到安全地点的磁带拷贝，其上的数据已有数小时的延迟，而在灾难或各种故障出现系统需要立即恢复，必须将磁带提取出来，并运送到恢复地点，通常还要滞延几个小时。
基于磁带拷贝方式的传统灾难备份方式有着明显的缺陷，越来越不适合用户不断发展的业务系统的需要。其备份和恢复过程非常复杂，数据延迟较大，磁带管理困难，数据恢复必须按照正确的顺序，出错的可能性也较大。
数据库复制是目前最流行的高可用解决方案。每种数据库系统来实现的机制和方式略有不同，但都包括逻辑复制和物理复制两种方式：
逻辑复制指针对数据库的逻辑层数据进行复制，复制的基本单位为数据库表以及表中所有的数据，复制时采用标准的TCP/IP协议。这种复制方法的好处是复制的数据量少，网络资源占用低，在复制的过程中目标数据库可以被访问，企业可以将目标系统用于报表和查询系统。同时因为目标数据库处于启动状态，接管时不需要重新启动数据库，接管可以接近实时。
物
理复制方法主要通过日志文件的传送和应用实现的。数据库交易的复制机制利用日志的这种特性，在生产中心将日志传输到灾备中心；如果灾备中心的数据库结构和
生产中心的数据库结构保持一致，则灾备中心的数据库对日志中记载的交易执行前滚操作，即实现了对灾备中心数据库数据的更新。
数据库级别的复制可以支持计划内停机时间、计划外的停机时间和应用可以允许一些损失的情况下进行灾难恢复。
服务器卷方式复制嵌入到操作系统的卷管理系统中，卷发生的变化分为结构的变化和卷内容的变化。这种复制方式可以复制卷内容的变化。
服务器卷方式有两种复制方式，同步方式和异步方式。同步方式采用数据库两阶段提交的方法，对源系统的影响非常大。异步方式从数据的一致性保障方面存在问题。
由于卷复制部件使用服务器CPU、Memory资源，使用标准的TCP/IP网络，对业务的正常运行产生的较大的性能影响。
使用服务器卷方式进行复制，必须使用专用的卷管理软件，整个应用系统的结构需要根据卷管理的要求经过严格的设计和重新划分，同时，在后期的维护过程中也需要对卷结构的变化进行同步的维护，从而增加实施和维护方面的一些困难。
服务器卷方式复制对服务器的硬件平台、数据库版本有严格限制，局限于主机同构环境。
方式
智能存储方式利用磁盘系统自身的处理能力，通过磁盘系统之间的通道连接复制磁盘系统内的数据更新，从而在异地中心保存生产数据的记录。利用磁盘复制可以独立于服务器、操作系统、卷管理系统、数据库、文件系统、中间件、应用程序。
和服务器卷方式一样，智能存储两种复制方式，同步方式和异步方式。同步方式采用数据库两阶段提交的方法，对源系统的影响非常大。异步方式从数据的一致性保障方面存在问题。
智能存储系统方式复制使用存储上的CPU资源，但对IO资源的消耗比较大。这种方式复制速度很快，但这种复制方式对存储依赖非常强，主备服务器必须使用同样的存储设备，依赖于专有网络。因为在存储级进行复制，目标数据库处于不可用状态。当需要应用切换时，必须停止复制过程，Mount复制卷组，将操作系统启动，启动数据库，进行数据库恢复。所有这些工作一般手工进行，需要花费一定的时间。
采用智能存储系统方式进行复制，源系统和目标系统的硬件平台、操作系统、数据库版本必须一致。复制的内容包括所有底层数据，占用的网络带宽较高。而且目标系统无法访问。
介绍
目前，很多厂家都提供容灾保护的产品，主要包括基于存储、逻辑卷、主机、数据库物理方式和数据库逻辑方式的各种复制技术。根据复制层面的不同，实现的技术以及容灾效果各不相同。Quest Software的SharePlex for Oracle通过数据库逻辑层的复制技术，可以方便地实现基于Oracle数据库的容灾保护，具有对源系统资源占用少，对网络资源占用少，支持异构环境和不同的复制拓扑，保持事物一致性的特点。在开放异构环境、异地容灾、容灾系统可访问的环境中具有非常大的优势。
结构
(1)基本结构
下图所示为SharePlex for Oracle的基本结构，其中涉及较多的技术细节。
(2)数据捕获
SharePlex for Oracle中由捕获进程来收集发生变化的数据，此进程的独特之处在于它几乎不对生产数据库带来任何开销。
(3)数据传输
SharePlex结合其自己的网络协议和TCP/IP协议来完成源和目标系统之间的数据传输。其相关的进程确保数据的正确接收和网络数据包的正确顺序，从而提供网络传输冗余，确保数据的完整。整个数据传输过程无需其它的中间件。
(4)应用数据
应用进程将传送到目标系统中的信息转化为SQL语句，然后采用标准的SQL*Plus方式将SQL语句发送给Oracle执行。
SharePlex能够实现精确复制的一个重要原因就是其能保证从源数据库到目标数据库的Oracle读一致性，不但按顺序复制事务，而且也复制上下文信息。由于SharePlex将源数据库中发生变化的全部事务信息都复制到目标数据库中，因此SharePlex复制方案用于灾难恢复系统中是足够可靠的。
配置方案
SharePlex提供多种不同的配置方式以满足高可用性和负载均衡需求。主要包括：
（1）单向复制
SharePlex可以将源系统的数据实时复制到目标系统，从而建立一个可以被访问的即席查询和报表系统。目标系统可以是源系统的全集和子集。通过将查询和报表系统放在不同的数据库实例中运行，可以平衡服务器负载并提高OLTP类生产系统的性能。
（2）高可用性
保证数据高可用性和数据库系统能够从灾难中迅速恢复是一个非常具有挑战性的工作。SharePlex for Oracle可以通过LAN或WAN进行复制，这样当生产环境出现紧急事件或要进行例行维护时，可以将应用切换到复制数据库中。有了生产数据库的实时拷贝，用户可以保证应用系统7*24不间断运行的情况下进行维护工作，如进行操作系统和数据库的升级等等。
（3）分布处理
多数据源配置允许你将不同的用户分布到不同的服务器，让每个数据库能够反映其他数据库的变化。在这种配置模式下，SharePlex采用必要的冲突处理机制来解决可能发生的冲突。
（4）广播和集中复制
SharePlex for Oracle通过LAN或WAN进行实时复制，将生产数据库中的数据拷贝到需要它们的地方。对广播复制来说，远程用户可以访问这些实时数据而不用登录生产服务器。因此，提高了网络性能和生产环境下的OLTP应用的性能。
（5）企业环境的数据分布
SharePlex 支持层叠复制，可以向不是直接相连的数据库复制数据。使用这种配置，可以在远程数据库间进行复制（如从北京到上海）。SharePlex 支持多种复杂的场景来满足复制需求。
特点
SharePlex是非常快速的，同时保证了复制数据的精确性。在源数据库一端，SharePlex严格地遵守读一致性模式。在目标数据库一端，SharePlex使用标准SQL提交事务，并保证操作次序和会话上下文的一致。
基于Log的复制方式对源数据库和系统所带来资源开销非常小，因为复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。
每秒钟可针对数千个表复制超过一千个以上事务的处理能力意味着SharePlex可以处理企业级的业务数据，可以满足企业大数据量的吞吐需求。实际环境中的吞吐速率是受服务器性能、网络带宽和事务的复杂程度所影响的。
SharePlex 提供的完全复制程度是其它软件复制工具所不具备的。SharePlex支持带长列的表、带参照完整性约束的表、没有主键的表、序列等等的复制。此外，SharePlex复制ALTER TABLE等命令，使它可以不需要其它软件复制工具就复制DDL活动。
SharePlex在设计时已经将性能和容灾因素考虑在内。SharePlex可以容忍实例失败、系统失败和网络失败。一般情况下，在源系统中运行的事务一旦被写入log，SharePlex立即将其发送到目标系统。然而，如果发生问题，SharePlex可以在源系统或目标系统进行事务排队(为了最小化对源系统的影响，排队位于Oracle源实例之外)。例如，如果网络宕掉或目标系统宕掉，SharePlex将源系统中的事务排队。当网络或系统恢复后，SharePlex将自动提交被排队的数据并清空队列文件。
SharePlex可以被灵活配置，以支持各种复制策略。包括单向复制、双向复制、广播复制、集中复制及多层复制等。
SharePlex是独立的软件，不需要修改与数据库进行交互的应用程序和数据库本身。因此，安装非常简洁。配置和改变复制策略不影响源数据库系统中的生产活动。管理员可以用Windows界面或服务器端的命令行管理和监控复制操作的各个方面。
适用场合
(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可以实时捕捉、转换数据到决策支持系统中。
为方便论述，本节模拟地点A和B，两地各有一套运行在Oracle上的应用系统。通过SharePlex for Oracle建立数据复制，以B地点的系统作为A地点的备份。
一、 正常情况下：
ü 业务系统运行在地点A，包括数据库实例、有关的文件、数据库数据、应用软件。A节点对外提供服务。
ü A节点所有的有关的数据通过SharePlex for Oracle实时复制到B节点。
二、 灾难发生的情况下，整个A地点无法正常提供服务：
ü A地点的业务将在B地点正常提供服务。当灾难发生时，主中心的数据库服务、应用软件切换到灾备中心的灾备节点。灾备节点对外提供服务。
ü 数据复制暂停。
ü 对主中心的数据库和应用系统进行恢复。
三、 计划内维护操作
ü 当进行计划内的维护时，主中心的数据库服务、应用软件切换到灾备中心的灾备节点。灾备节点对外提供服务。
ü SharePlex for Oracle记录进行维护期间数据的变化，存储到灾备节点的队列。
ü 当计划内的维护操作时完成时，将维护过程中的数据复制到A地点，将应用切换到A地点系统。
使用SharePlex for Oracle进行数据复制的前提是在主中心和灾备中心具有相同的数据。根据用户对停机时间的要求、容灾环境和数据量的大小。可以采用Oracle自身提供的方法进行初始化同步，包括：Oracle Cold Backup，Oracle Hot Backup，Export/import，Transprant tablespace等等。
为了保证初始化同步过程中源系统的可用性，SharePlex 提供Reconcile 功能，当使用Oracle Hot backup 机制进行初始化同步时，通过SharePlex队列记录数据的变化。并在进行post的过程中确认哪些数据通过Recovery进行恢复，把没有恢复的数据装载到数据库中。从而保证初始化同步过程中源系统没有停机时间。
为保证灾难发生时快速进行应用接管，需要配置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文件
灾难发生时的接管工作由以下步骤组成：
ü 确认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分钟以内的切换要求。
从容灾中心的数据恢复到主中心的过程分为如下阶段：
ü 阶段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个小时之间。
Shareplex failover接管
ü 在Primary系统上停止用户对数据对象的访问；
ü 在Primary系统，运行flush命令，此命令停机目标机器上的post进程，并将队列中的内容装载到数据库中。
ü 关闭Primary中的SharePlex和Oracle数据库。
ü 运行脚本为Secondary系统的oracle用户赋insert, update和delete的权限；
ü 运行脚本激活Secondary系统的oracle trigger和contraints；
ü 按照相应步骤重新部署用户和应用到Secondary系统；
ü 切换用户到Secondary系统，但不要启动export进程；
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进程；
关键技术指标
SharePlex for Oracle是一种异步准实时的复制技术，其数据延迟非常小。在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，数据延迟在几秒钟。
复制环境能够提供网络失败、数据库失败、主机失败的容错能力。当灾备中心暂停或传输异常中断导致复制停止时，主中心的业务不受影响，容灾数据可以在主中心暂时存放，当系统恢复后，暂存数据可自动完整复制到灾备中心，数据完整性一致性不被破坏；
SharePlex for Oracle通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用小于6个百分点，对内存资源的占用为几十M。
因为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。
继续……
