Oracle数据库异地容灾方案概述

{管理信息化ORACLE}Oracle数据库异地容灾方案概述Oracle数据库异地容灾方案介绍2008年11月目录第一章需求分析41.1序言41.2用户现状41.2.1系统平台41.2.2数据库平台61.3用户需求71.3.1日常功能71.3.2故障切换71.3.3基本要求71.3.4性能要求81.3.5数据一致性91.3.6系统兼容性91.3.7高可用性101.3.8健壮性要求101.3.9设备无关性101.3.10管理监控功能11第二章OracleDataGuard介绍122.1DataGuard实现原理122.2OracleDataGuard优势152.3DataGuard提供的保护模式162.4DataGuard实现方式以及对系统的限制要求172.5切换方式17第三章系统建议方案183.1DataGuard优势183.2DataGuard运行模式193.3DataGuard保护模式193.4DataGuard初始安装步骤193.5用户需求点对点应答203.5.1日常功能203.5.2故障切换213.5.3基本要求223.5.4性能要求233.5.5数据一致性243.5.6系统兼容性253.5.7高可用性253.5.8健壮性要求263.5.9设备无关性273.5.10管理监控功能27第一章需求分析1.1序言GartnerGroup停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。有句古谚叫“别把鸡蛋放在一个篮子里。现在的信息系统，各种数据高度集中，“鸡蛋”全放在一个篮里了。一旦出现突然停电、意外死机或者人为破坏，造成数据丢失是不可避免的。面对各种未可预知的灾难，越来越多的企业将容灾备份系统作为企业安全的保障。银联数据异地灾备项目的目标是保证SF25K迁移至IBMIBMP570，减少公司各方面的损失，保证发卡系统的业务连续性。本方案仅对异地容灾数据库复制软件部分做相应阐述。1.2用户现状1.2.1系统平台发卡系统运行在一台SunFireE25K企业级服务器上，通过两台BrocadeSW4900SAN交换机与两台企业级存储ST9990、SE9970相连，应用系统核心文件和数据库数据文件均存放在该存储上，存储系统磁盘采用RAID1+0方式。SF25K划分为四个物理分区（Domain），每家银行均使用其中的两个，一个DomainDomain作为热备主机。Domain操作系统为Solaris10，数据库系统为Oracle10.2.0.2RACSunCluster的双机热备份，保证了系统的高可用性。此外，在主机端还通过SunMPXIO多通道负载均衡软件，实现两条光纤通道的负载均衡，进一步避免了单点故障。以下是发卡系统SAN架构图：DomainASF25KDomainBDomainCDomainDSW4900

SW4900SE9970ST9990V280R

VTLL180(2LTO-3)NBUMasterServer通过在主机端使用VxVM4.1存储SE9970与ST9990之间实现了同步数据复制，达到了以下灾难恢复目标：日常工作，保证两台存储的数据实时同步保持一致，所有数据不丢失。计划外停机，任一台存储发生灾难，保证数据不丢失，即RPO=0，并确保应用不中断运行，即RTO=0。1.2.2数据库平台卡系统的业务运转直接依赖于这些数据的可用性。为了确保数据库的高可用性，发卡系统数据库使用了Oracle10gRAC版本10.2.0.2，主、备机两节点的数据库实例同时运行，一旦主节点出现问题，数据库实例无需启停，可迅速将应用系统切换至备节点。截至到2008年8月底，各数据库实例数据量情况见下表：实例名总数据量（GB）Archivelog数据量（GB）平均每天最大帐单日高峰期Archivelog变化量（MB/s）HX25140.42SZ15120.20CR934.550.40DE381.550.58UC27512162.95合计44620324.551.3用户需求以保证生产数据的安全性，满足发卡系统的业务连续性需求。1.3.1日常功能将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；灾备中心的Oracle数据库处于打开状态，可提供实时数据查询；对生产系统的资源占用不能太多，不能影响到生产系统的正常运行；对网络带宽的占用较低。1.3.2故障切换当生产中心的系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。灾备中心必须在生产中心不可用6小时之内完成业务接管。当生产中心服务器恢复正常后，数据复制系统需要将灾备中心的最新数据反向复制回生产中心，实现业务的恢复。1.3.3基本要求复制软件应满足在单机或RAC环境下，对Oracle在线日志(Onlineredolog)的捕捉及复制；支持Oracle中所有的常用数据类型，如Oracle中的LONG、LONGRAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；支持对数据库中常用DDL操作的复制；支持事务复制，要求对数据库中较大的事务不会出现过多延迟；支持没有PK/UK字段的表的同步。数据复制过程可根据需要灵活地进行控制或修改复制的方向，以满足业务需求；支持在数据复制过程中对数据正确性进行校验，如正在复制的数据在之前就已经不一致，应提供报警功能，以便及时发现错误，避免错误的扩大；提供专用图形化集中管理软件。1.3.4性能要求数据库初始化同步要求数据库复制软件能够将发卡系统的数据库中已有数据初始化同步到灾备中心数据库。在初始化同步过程中，业务不能停止，但可选择业务量较小时段进行。在解决方案书中要求详细描述初始化数据同步解决方案，以及整个首次同步操作所100GB人为干预，从而可以有效地评估整个首次数据初始化的工作量。为了保证生产中心日后业务扩展存在更换服务器厂商以及数据库版本等情况，需要注明是否支持异构平台下的首次数据初始化同步，是否支持跨数据库版本之间数据库的初始化同步操作。数据复制性能指标数据复制的性能指标与系统平台、网络带宽、应用系统等因素密切相关，参照下列运行环境：项目配置数据源SF15K24个CPU，32GB内存，ORACLE10.2.0.2RAC目标端SF15K24个CPU，32GB内存，ORACLE10.2.0.2总数据量500GB左右（数据+索引）每天的日志量每天20GB日志网络带宽100M和20M要求提供相应的性能参数指标：类别指标参考值首次数据初始化同步首次数据库初始化同步时间（100M带宽）小于10小时首次数据库初始化同步时间（20M带宽）小于48小时首次数据库初始化同步源端CPU占用小于30％源端CPU占用小于5％增量数据同步（单个复制链路）目标端CPU占用小于5％源端内存占用小于200M目标端内存占用小于200M复制数据延迟平均值10s以内源端CPU占用小于10％业务高峰期对系统的影响目标端CPU占用小于10％复制数据延迟平均值10s以内1.3.5数据一致性要求数据库复制软件提供数据库初始化同步、数据恢复后以及日常的数据一致性检查方案，要求方案中详细注明该数据一致性比对方案的特点以及操作复杂度，并可满足如下要求：可在应用不停机的情况下，查找和发现不一致的数据；一致性检查需要能够进行对象属性、记录条数和记录的字段内容进行一致性检查；提供全库的记录级一致性检查时间（以100GB支持不含PK/UK字段的表的一致性检查和修复。请提供在没有PK/UK字段的表中有1000万条记录的比对时间。对于不一致的数据，需要提供不一致记录详细信息，以便进行精确的修复，同时提供数据修复方案。数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。1.3.6系统兼容性数据库复制软件应支持以下操作系统平台：SunSolaris9,10IBMAIX5.x数据库复制软件应支持Oracle9i，Oracle10g，Oracle11g及后续数据库版本；支持异构平台，源端和目标端不同数据库版本；支持Cluster/HACMP和RAC模式，并支持不同操作系统下不同数据库版本之间的复制。1.3.7高可用性主系统和备用系统的数据库处于双活状态，以保证在灾难发生前可在两个系统上运行不同类型的应用程序。数据库复制软件应支持本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可通过Cluster软件接管到其它节点。1.3.8健壮性要求数据库复制软件在各种大压力和各种故障情况下不会造成数据复制失败。网络故障：长时间中断、短时间中断及网络时断时续情况下的正常复制；数据库故障：在目标端数据库故障下，源端数据库不能受到影响。当目标端数据库修复后，复制软件继续工作；服务器硬件故障：在目标端服务器故障下，源端生产系统不能受到影响，当目标端修复后，复制软件继续工作。1.3.9设备无关性Oracle台之间数据库的复制。1.3.10管理监控功能数据库复制软件需提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时具有完整方便的报警及跟踪机制，方便故障的快速定位和解决。第二章OracleDataGuard介绍容灾系统主要包括数据保护和应用切换两大方面，其中最为重要的是数据保护部分。除了要将这些数据存放在高可用的存储设备上之外，最重要的是这些关键数据应该在异地之间保持一致，以使灾难发生后，系统可以尽快恢复。下面是几种主要的数据保护技术。实现数据的异地复制，有软件方式和硬件方式两种途径。软件方式，是通过主机端软件来实现，如第三方软件或者数据库厂家提供的远程数据容灾工具来实现业务数据的远程复制。硬件方式，是基于智能存储系统的控制器的远程拷贝，可以在主、备存储系统之间通过硬件实现复制。在实际的容灾系统中，由于系统的环境不同，安全性要求不同以及采用的软硬件产品不同，数据复制过程中的工作机制也不尽相同。概括地讲，数据复制地工作机制主要包括同步和异步两种。同步远程镜像(同步复制技术)是指通过远程镜像软件，将本地数据以完全同步的方式复制到异地，每一本地的I/O事务均需等待远程复制的完成确认信息，方予以释放。异步远程镜像(异步复制技术)保证在更新远程存储视图前完成向本地存储系统的基本I/O操作，而由本地存储系统提供给请求镜像主机的I/O操作完成确认信息，远程的数据复制以后台同步的方式进行。因为带宽等因素限制，本次容灾方案仅包括了异步复制的方式的讨论。2.1DataGuard实现原理OracleDataGuard是当今保护企业核心资产（数据）的最有效解决方案，它能够使数据在24x7的基础上可用，而无论是否发生灾难或其它中断。OracleDataGuard是管理、监控和自动化软件的基础架构，它创建、维护和监控一个或多个备用数据库，以保护企业数据结构不受故障、灾难、错误和崩溃的影响。DataGuard使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千公里的远程灾难恢复站点，或者可能位于同一城市、同一校园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时，DataGuard可以将任意备用数据库切换到生产角色，从而使与中断相关的停机时间减到最少，并防止任何数据丢失。作为Oracle数据库企业版的一个特性推出的DataGuard能够与其它的Oracle高可用性(HA)(RAC)和恢复管理器(RMAN)提供业内前所未有的高水平数据保护和数据可用性。下图提供了OracleDataGuard的一个概述。OracleDataGuard包括一个生产数据库，也称为主数据库，以及一个或多个备用数据库，这些备用数据库是与主数据库在事务上一致的副本。DataGuard利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入本地重做日志文件中。通过DataGuard，还将重做数据传输到备用站点上，并应用到备用数据库中，从而使备用数据库与主数据库保持同步。DataGuard允许管理员选择将重做数据同步还是异步地发送到备用站点上。备用数据库的底层技术是DataGuard重做应用（物理备用数据库）和DataGuardSQLOracle个独立数据库，它与主数据库包含相同的数据。它使用SQL语句进行更新，其相对优势是能够并行用于恢复以及诸如报表、查询等其他任务。DataGuard简化了主数据库和选定的备用数据库之间的转换和故障切换，从而减少了由计划停机和计划外故障所导致的总停机时间。主数据库和备用数据库以及它们的各种交互可以使用SQL*Plus来进行管理。为了获得更简便的可管理性，DataGuard还提供了一个分布式管理框架（称为DataGuardBrokerDataGuard配置的创建、维护和监控，并对这OracleEnterpriseManager或Broker自己的专用命令行界面(DGMGRL)来利用Broker的管理功能。下图显示了OracleDataGuard组件。2.2OracleDataGuard优势灾难恢复和高可用性—DataGuard提供了一个高效和全面的灾难恢复和高最少。完善的数据保护—使用备用数据库，DataGuard可保证即使遇到不可预见的灾难也不会丢失数据。备用数据库提供了防止数据损坏和用户错误的安全保护。用数据库时会对其进行验证。有效利用系统资源—备用数据库表使用从主数据库接收到的重做数据进行CPU和I/O用数据库，用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。查询性能和适应特定的业务要求。灵活的数据保护功能，从而在可用性与性能要求之间取得平衡—OracleDataGuard业在系统性能要求和数据保护之间取得平衡。自动间隔检测及其解决方案—如果主数据库与一个或更多个备用数据库之DataGuard就自动检测丢失的存据库将重新与主数据库同步，而无需管理员的任何手动干预。简单的集中式管理—DataGuardBroker使一个DataGuard配置中的多个数据库间的管理和操作任务自动化。Broker还监控单个DataGuard配置内的所有系统。管理员可以使用OracleEnterpriseManager或Broker自己专用的命令行界面(DGMGRL)来利用这个集成的管理框架。与Oracle数据库集成—OracleDataGuard是作为Oracle数据库（企业版）的一个完全集成的功能提供的，无需任何额外费用。2.3DataGuard提供的保护模式Oracle针对用户的不同需求提供三种保护模式：最大保护模式、最大性能模式、最大可用模式。Oracle提供的DataGuard在最大保护模式下可以确保数据完全不丢失。它在写本地日志的同时写远程standby10%网路链路还是standby数据库等发生故障导致日志无法正常写均会导致主数据库无法使用。因此只有在对数据安全要求最高的情况下才会考虑使用这种方式。Oracle也提供最大性能模式。这种模式下，不传输实时修改的日志文件，standby数据难发生的时候备份数据库与主数据库可能有一定的数据差异。Oracle提供的第三种模式是上述两种方式的折中。在网络正常的情况下它standby出现故障的大影响，而且对网络链路要求较高。综上所述，不同的保护模式比较如下：最大保护最大可用最大性能对主数据库性能影响较高较高低对网络链路要求极高高低备份系统发生故障主数据库不可用无影响无影响数据保护无数据丢失基本无数据丢失少量数据丢失2.4DataGuard实现方式以及对系统的限制要求Oracle针对不同的用户情况提供的两种不同的standby方式。物理standby,逻辑standby。物理standby数据库，在通常的模式下备份库始终处于恢复状态，用户无做恢复与主数据保持一致。Oracle还提供逻辑standby数据库。这种方式下数据库可以在打开的状态下保持与主数据库的同步工作。这种打开状态和普通的数据库open状态不同，standby一性索引。无论是物理standby还是逻辑standby均对系统要求如下:SUN大小、CPU数量主频可以不同。操作系统版本、补丁完全相同。RACRAC模式，备份节点可以是单机。2.5切换方式OracleDataGuard可以实现failover以及switchover的切换。Switchover指有计划的切换。如系统主数据库服务器需要硬件维护等有计后执行switchover的切换。这种情况下等主数据库恢复正常后系统可以手工切换回来。Failover切换是指系统出现了异常情况下的切换。系统管理员发现主数据库服务器恢复正常后需要重新配置整个DataGuard务器。IP要修改服务器IP地址或应用程序重新指向。因为在不同的局域网内，应用中间这需要在容灾的预案中考虑。第三章系统建议方案针对本容灾方案，我们推荐采用OracleDataGuard技术。3.1DataGuard优势节约投资OracleDataGuard是Oracle原厂自带的容灾产品。该产品完全免费。在容灾软件上用户无需支付额外费用，这可以大大节约用户的资金投入。技术成熟、稳定早在Oracle7版本就已经推出该功能（当时名称为Standby用了Oracle成熟的归档、备份、恢复技术。经过多年不断的发展，已经成为一项技术成熟、稳定，有广泛成功案例的技术。对系统运行性能影响小DataGuard器端将归档日志文件传输到容灾节点。因此对生产系统性能影响极小。能够满足用户基本业务需求DataGuard能够满足用户基本的数据容灾、RTORPO3.2DataGuard运行模式Oracle提供了物理DataGuard以及逻辑DataGuard两种不同的方式。这两种方式各有优缺点。因为用户数据库中存在大量表，这些表没有PK/UK法满足逻辑DataGuard的使用前提条件。在本方案中，我们推荐采用物理DataGuard的方式。3.3DataGuard保护模式根据用户的实际情况，在主数据库服务器和容灾数据库服务器之间距离较允许在出现异常情况下15分钟内的数据丢失量，因此采用最大性能模式可以在现有带宽的情况下满足用户的容灾需求。standby数据库出现异常也不会影响主与主数据库可能有一定的数据差异。3.4DataGuard初始安装步骤1、确认主数据库运行于归档模式如果主数据库没有处于归档模式，那么需要将数据库运行模式修改为归档模式。该修改过程需要短暂停止数据库运行。2、物理备份主数据库的所有数据文件该部分工作可以在不影响业务正常运行的情况下执行。该部分工作依据数据量以及I/O速度不同，所需要的时间也不同。一般估算，100G的数据应在1小时内备份完成。该备份操作启动后无需人为干预。3、在主数据库创建standby控制文件通过命令创建灾备中心的控制文件。4、拷贝备份的数据文件、standby控制文件及日志文件到备份节点。100G的备份文件经压缩，通常压缩率在40%-50%100G文件压缩后约50G20M带宽的情况下，假设网络利用率为70%，那么速度约为6G/每小时；50G的文件需要9个小时传递完成。在网速为100M带宽的情况下，假设网络利用率为70%，那么速度约为30G/50G的文件需要1.5个小时传递完成。在数据传输启动后无需人为干预。5、配置主、备中心的数据库服务器DataGuard环境该操作对主数据库运行没有任何影响。其中灾备中心数据库平台要求与主中心架构一致，如均为SUN小型机。操作系统版本及数据库版本均需要一致。DataGuard容灾。6、使用主中心备份的文件创建灾备中心数据库系统。该操作主要是解压文件、恢复数据文件的时间。约为2小时。73.5用户需求点对点应答3.5.1日常功能将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；应答：满足。DataGuard通过归档日志将数据库变化复制到灾备中心。灾备中心的Oracle数据库处于打开状态，可提供实时数据查询；DataGuard在正常恢复的时候无法处于打开状态，在打开的状态下无法处于恢复与主数据库保持一致的状态。本系统的RPO<15分钟，RTO<6小时，每天归档日志产生量<20G。可以考虑以下方式解决该问题：如果用户对容灾数据库使用时间为白天，那么在白天，将数据库启动为只读，白天数据库做恢复。容灾中心数据库只在指定时间内对数据库做恢复，因此该数据库与主数据库之间存在1会同步写入容灾中心，因此系统可以满足RPO<15分钟的要求。当出现需要启动志量<20G，系统使用这些归档日志恢复数据的时间<2小时，能够满足RTO<6小时的业务需求。如果用户对容灾中心数据库使用为全天24DataGuard无法满足要求，在Oracle11G以后的版本提供该功能。对生产系统的资源占用不能太多，不能影响到生产系统的正常运行；DataGuard的最大性能模式，生产中心主机仅需要在归档产系统的正常运行。对网络带宽的占用较低。DataGuard传输内容数据变化产生的归档日志文件。目前每天归档日志产生量为20G，那么传输量为20G/天。3.5.2故障切换备中心提供业务接管。应答：满足。灾备中心可以提供数据库服务器。灾备中心必须在生产中心不可用6小时之内完成业务接管。应答：满足。灾备中心可以在6小时内完成业务接管。据反向复制回生产中心，实现业务的恢复。应答：部分满足。系统切换可以分为有计划的停机以及故障停机。在有计划停机的情况下，灾备中心数据库在启用的时候，数据库内容保持用期间数据修改反向复制回生产中心，实现业务的恢复。(<15分钟)尚未传递到备份中新传递回主中心才能实现业务的恢复。3.5.3基本要求复制软件应满足在单机或RAC环境下，对Oracle在线日志(Onlineredolog)的捕捉及复制；DataGuard通过对Onlineredolog产生的归档文件复制来完成容灾。支持Oracle中所有的常用数据类型，如Oracle中的LONG、LONGRAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；应答：满足。物理DataGuard支持Oracle中所有的常用数据类型支持对数据库中常用DDL操作的复制；应答：满足。物理DataGuard支持Oracle中常用DDL的操作复制。支持事务复制，要求对数据库中较大的事务不会出现过多延迟；应答：满足。物理DataGuard支持事务复制。对较大事务不会出现过多延迟。支持没有PK/UK字段的表的同步。应答：满足。物理DataGuard支持没有PK/UK字段的表的同步。务需求；应答：满足。DataGuard可以灵活地控制主、备节点的swithover切换。前就已经不一致，应提供报警功能，以便及时发现错误，避免错误的扩大；DataGuard复制的前提条件是主、备数据库保持一致，因此不会出现复制的数据在之前已经不一致的情况。提供专用图形化集中管理软件。应答：满足。DataGuardBroker与OEM可以提供很方便的图形化集中管理。3.5.4性能要求数据库初始化同步要求数据库复制软件能够将发卡系统的数据库中已有数据初始化同步到灾备中所需要的时间（以100GB否需要人为干预，从而可以有效地评估整个首次数据初始化的工作量。数据库的初始化同步操作。应答：满足。详见DataGuard初始安装步骤数据复制性能指标照下列运行环境：项目配置数据源SF15K24个CPU，32GB内存，ORACLE10.2.0.2RAC目标端SF15K24个CPU，32GB内存，ORACLE10.2.0.2总数据量500GB左右（数据+索引）每天的日志量每天20GB日志网络带宽100M和20M要求提供相应的性能参数指标：类别指标参考值应答首次数据初始化同步首次数据库初始化同步时间（100M带宽）首次数据库初始化同步时间（20M带宽）首次数据库初始化同步源端CPU占用小于10小时小于48小时小于30％满足，首次初始化同步时间小于5小时12小时1%源端CPU占用小于5％1%目标端CPU占用小于5％5%增量源端内存占用小于200M满足，对主资源消耗极小。无需额外内存消耗数据同步目标端内存占用小于200M满足，对主资源消耗极小。无需额外内存消耗（单个不满足。在最大性能模式下，物理复制链DataGuard在日志切换后将改变的数路）复制数据延迟平均值10s以内据写入灾备中心。频繁的日志切换将影响数据库运行性能。建议将日志切换频率设置为10最大延迟约为10分钟。业务高源端CPU占用小于10％1%峰期对目标端CPU占用小于10％5%系统的不满足。在最大性能模式下，物理影响DataGuard在日志切换后将改变的数复制数据延迟平均值10s以内据写入灾备中心。频繁的日志切换将影响数据库运行性能。建议将日志切换频率设置为10最大延迟约为10分钟。3.5.5数据一致性度，并可满足如下要求：可在应用不停机的情况下，查找和发现不一致的数据；致性检查；提供全库的记录级一致性检查时间（以100GB支持不含PK/UKPK/UK字段的表中有1000万条记录的比对时间。对于不一致的数据，需要提供不一致记录详细信息，以便进行精确的修复，中不影响业务正常运行。DataGuard动的。当系统发生Switchover的切换以后，主备关系变化，同样只有主数据库（原来的备数据库）可以修改，备数据库（原来的主数据库）是不可以修改