OracleDataGuard容灾方案

(完整版)OracleDataGuard容灾方案(完整版)OracleDataGuard容灾方案(完整版)OracleDataGuard容灾方案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第三章系统建议方案.....................................................................................................193.1DataGuard优势.................................................................................................193.2DataGuard运行模式.........................................................................................193.3DataGuard保护模式.........................................................................................203.4DataGuard初始安装步骤203.5用户需求点对点应答213.5.1平时功能213.5.2故障切换223.5.3基本要求233.5.4性能要求233.5.5数据一致性253.5.6系统兼容性263.5.7高可用性263.5.8强健性要求273.5.9设施无关性273.5.10管理监控功能28第一章需求剖析1.1前言在信息时代，数据是公司创立商业价值的生产资料，数据的丢掉将为公司带来毁坏性的灾难。据GartnerGroup的检查数据表示，在经历过大型灾难或长时间系统停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。有句古谚叫“别把鸡蛋放在一个篮子里”。现在的信息系统，各样数据高度集中，“鸡蛋”全放在一个篮里了。一旦出现突然停电、意外死机或许人为破坏，造成数据丢掉是不可防止的。面对各样未可预知的灾难，越来越多的公司将容灾备份系统作为公司安全的保障。银联数据异地灾备项目的目标是保证SF25K上各银行（民生银行贷记卡系统拟迁移至IBM主机，故此次灾备项目暂不考虑；邮储银行贷记卡系统主机为IBMP570，也不在考虑范围之内）发卡系统的安全，在灾难情况下，最大限度地保护公司财产，减少公司各方面的损失，保证发卡系统的业务连续性。本方案仅对异地容灾数据库复制软件部分做相应阐述。1.2用户现状1.2.1系统平台发卡系统运行在一台SunFireE25K公司级服务器上，经过两台BrocadeSW4900SAN互换机与两台公司级存储ST9990、SE9970相连，应用系统核心文件和数据库数据文件均寄存在该存储上，存储系统磁盘采用RAID1+0方式。SF25K区分为四个物理分区（Domain），每家银行均使用其中的两个，一个Domain作为生产主机，另一个Domain作为热备主机。Domain操作系统为Solaris10，数据库系统为Oracle10.2.0.2RAC。经过SunCluster集群软件，实现了生产机房内的双机热备份，保证了系统的高可用性。别的，在主机端还经过SunMPXIO多通道负载平衡软件，实现两条光纤通道的负载平衡，进一步防止了单点故障。以下是发卡系统SAN架构图：DomainASF25KDomainBDomainCDomainDSW4900SW4900SE9970ST9990V280RVTLNBUMasterServerL180(2LTO-3)经过在主机端使用VxVM4.1卷管理软件，已成立了同机房数据灾备系统，两台存储SE9970与ST9990之间实现了同步数据复制，达到了以下灾难恢复目标：平时工作，保证两台存储的数据实时同步保持一致，所有数据不丢掉。 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 外停机，任一台存储发生灾难，保证数据不丢掉，即RPO=0，并保证应用不中止运行，即RTO=0。生产主机VxVMMirrorVolumeSE9970ST99901.2.2数据库平台发卡系统中的数据库系统，是整个生产系统中最重点、最复杂的数据对象，发卡系统的业务运转直接依靠于这些数据的可用性。为了保证数据库的高可用性，发卡系统数据库使用了Oracle10gRAC版本10.2.0.2，主、备机两节点的数据库实例同时运行，一旦主节点出现问题，数据库实例无需启停，可快速将应用系统切换至备节点。截止到2008年8月底，各数据库实例数据量情况见下表：实例总数据量（GB）Archivelog数据量（GB）变化量（MB/s）顶峰期Archivelog名平均每日最大帐单日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重做应用（物理备用数据库）和DataGuardSQL应用（逻辑备用数据库）。物理备用数据库在磁盘上拥有和主数据库逐块相同的数据库构造，并且使用Oracle介质恢复进行更新。逻辑备用数据库是一个独立数据库，它与主数据库包含相同的数据。它使用SQL语句进行更新，其相对优势是能够并行用于恢复以及诸如报表、查问等其他任务。DataGuard简化了主数据库和选定的备用数据库之间的变换和故障切换，进而减少了由计划停机和计划外故障所致使的总停机时间。主数据库和备用数据库以及它们的各样交互能够使用SQL*Plus来进行管理。为了获得更简易的可管理性，DataGuard还提供了一个散布式管理框架（称为DataGuardBroker），它不只自动化了DataGuard配置的创立、维护和监控，并对这些操作进行统一管理。管理员能够使用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在最大保护模式下能够保证数据完全不丢掉。它在写本地日志的同时写远程standby的数据库日志。只有两个日志均写成功后一个操作才是正式达成。这种方式保证了数据的最大安全，能够保证主数据库破坏的情况下没有任何数据丢掉。但这种情况对主数据库性能有较大的影响，即便在高速的局域网内，最大保护模式也会对主数据库性能有超过10%的性能影响。这种方式对主备两个数据库之间的链路有特别高的要求。在这种保护模式下不论是网路链路仍是standby数据库等发生故障致使日志无法正常写均会致使主数据库无法使用。因此只有在对数据安全要求最高的情况下才会考虑使用这种方式。Oracle也提供最大性能模式。这种模式下，不传输实时改正的日志文件，传达的是归档日志文件，因此对主数据库性能影响很小。归档日志文件传达是否能够成功对主数据库运行没有任何影响，因此在网络出现中止或许standby数据库出现异样也不会影响主数据库的正常运行。但因为日志没有同步写，因此在灾难发生的时候备份数据库与主数据库可能有一定的数据差别。Oracle提供的第三种模式是上述两种方式的折中。在网络正常的情况下它的运行方式近似于最大保护模式，日志实时传达。当网络或standby出现故障的时候它的运行模式近似于最大性能模式，日志延迟传达，不会致使主数据库停止运行。这种方式在正常情况下因为日志实时传达，因此同样对主数据库性能有较大影响，而且对网络链路要求较高。综上所述，不同的保护模式比较如下：最大保护最大可用最大性能对主数据库性能影响较高较高低对网络链路要求极高高低太极计算机股份有限公司备份系统发生故障主数据库不可用无影响无影响数据保护无数据丢掉基本无数据丢掉少量数据丢掉2.4DataGuard实现方式以及对系统的限制要求Oracle针对不同的用户情况提供的两种不同的standby方式。物理standby,逻辑standby。物理standby数据库，在往常的模式下备份库始终处于恢复状态，用户无法接见备份库的数据。如果需要接见数据，需要将恢复模式停止，将数据库翻开到只读状态。这两种状态是排它的，也就是说数据库要么是恢复状态，保持和主数据库一致，在这种状态下数据库内容不可接见；要么是只读状态，数据库不会做恢复与主数据保持一致。Oracle还提供逻辑standby数据库。这种方式下数据库能够在翻开的状态下保持与主数据库的同步工作。这种翻开状态和普通的数据库open状态不同，不能对数据做改正。这种方式往常用于忙碌的系统，如主数据库平时达成业务办理，逻辑standby数据库在达成容灾的同时分担主数据库的查问统计工作。这样大大节俭了系统资源。但这种方式对数据库有一定的限制，并不是所有的系统都能够支持。部分较为特殊的数据种类不支持，此外所有的表必须要有主键或许唯一性索引。不论是物理standby仍是逻辑standby均对系统要求如下:主备数据库必须是完全相同的硬件架构，如均为SUN平台。机器的内存大小、CPU数量主频能够不同。操作系统版本、补丁完全相同。数据库版本完全相同。但RAC选件能够不同。即主数据库能够是RAC模式，备份节点能够是单机。2.5切换方式OracleDataGuard能够实现failover以及switchover的切换。Switchover指有计划的切换。如系统主数据库服务器需要硬件维护等有计划的停机操作。这时候能够手工将所有的日志以及归档日志文件传输到备份节点太极计算机股份有限公司后履行switchover的切换。这种情况下等主数据库恢复正常后系统能够手工切换回来。Failover切换是指系统出现了异样情况下的切换。系统管理员发现主数据库服务器无法提供服务，决定启动容灾系统。在这种情况下的切换后如果主数据库服务器恢复正常后需要从头配置整个DataGuard环境，无法切换回主数据库服务器。不论是那种切换方式，主备系统之间均存在部分差别。如IP地点不同，需要改正服务器IP地点或应用程序从头指向。因为在不同的局域网内，应用中间件需要跨防火墙接见系统。机器品位不同、网络带宽不同造成的性能下降等问题。这需要在容灾的预案中考虑。太极计算机股份有限公司第三章系统建议方案针对本容灾方案，我们介绍采用OracleDataGuard技术。3.1DataGuard优势节俭投资OracleDataGuard是Oracle原厂自带的容灾产品。该产品完全免费。在容灾软件上用户无需支付额外费用，这能够大大节俭用户的资本投入。技术成熟、稳定早在Oracle7版本就已经推出该功能（当时名称为Standby数据库）。其核心采用了Oracle成熟的归档、备份、恢复技术。经过多年不断的发展，已经成为一项技术成熟、稳定，有宽泛成功案例的技术。对系统运行性能影响小DataGuard在主数据库服务器端不存在对日志解析等工作，仅需要主数据库服务器端将归档日志文件传输到容灾节点。因此对生产系统性能影响极小。能够知足用户基本业务需求DataGuard能够知足用户基本的数据容灾、RTO、RPO、带宽等有关基本业务需求。3.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文件压缩后约50G。在网速为20M带宽的情况下，假定网络利用率为70%，那么速度约为6G/每小时；50G的文件需要9个小时传达达成。在网速为100M带宽的情况下，假定网络利用率为70%，那么速度约为30G/每小时；50G的文件需要1.5个小时传达达成。在数据传输启动后无需人为干涉。太极计算机股份有限公司5、配置主、备中心的数据库服务器DataGuard环境该操作对主数据库运行没有任何影响。其中灾备中心数据库平台要求与主中心架构一致，如均为SUN小型机。操作系统版本及数据库版本均需要一致。DataGuard不支持异构平台数据容灾，也不支持不同数据库版本之间做数据容灾。6、使用主中心备份的文件创立灾备中心数据库系统。该操作主若是解压文件、恢复数据文件的时间。约为2小时。7、配置灾备中心环境。根据主中心的归档日志保持灾备中心与主中心一致。3.5用户需求点对点应答3.5.1平时功能将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；应答：知足。DataGuard经过归档日志将数据库变化复制到灾备中心。灾备中心的Oracle数据库处于翻开状态，可提供实时数据查问；应答：部分知足。物理DataGuard在正常恢复的时候无法处于翻开状态，在翻开的状态下无法处于恢复与主数据库保持一致的状态。本系统的RPO<15分钟，RTO<6小时，每日归档日志产生量<20G。能够考虑以下方式解决该问题：如果用户对容灾数据库使用时间为白天，那么在白天，将数据库启动为只读翻开模式，供业务查问。夜间，将数据库启动为恢复模式，保持与主生产中心一致。如果用户对容灾数据库使用时间为夜间，那么反之在夜间将数据库翻开只读，白天数据库做恢复。容灾中心数据库只在指准时间内对数据库做恢复，因此该数据库与主数据库之间存在1天的数据差别。虽然没有实时做数据恢复，归档日志文件在产生后会同步写入容灾中心，因此系统能够知足RPO<15分钟的要求。当出现需要启动备用中心的情况，备用中心需要先经过归档日志文件恢复数据。目前每日归档日志量<20G，系统使用这些归档日志恢复数据的时间<2小时，能够知足RTO<6太极计算机股份有限公司小时的业务需求。如果用户对容灾中心数据库使用为全天24小时，目前版本DataGuard无法知足要求，在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要求提供相应的性能参数指标：类型指标参照值应答首次数据库初始化同小于10小时知足，首次初始化同步时间小于5小步时间（100M带宽）时首次数首次数据库初始化同知足，首次初始化同步时间小于12据初始小于48小时步时间（20M带宽）小时化同步首次数据库初始化同知足，对主系统资源消耗极小。小于小于30％步源端CPU占用1%源端CPU占用小于5％知足，对主系统资源消耗极小。小于增量1%数据同目标端CPU占用小于5％知足，对目标资源消耗极小。小于5%步源端内存占用小于200M知足，对主资源消耗极小。无需额外（单个内存消耗复制链目标端内存占用小于200M知足，对主资源消耗极小。无需额外路）内存消耗复制数据延迟平均值10s以内不知足。在最大性能模式下，物理太极计算机股份有限公司DataGuard在日志切换后将改变的数据写入灾备中心。频繁的日志切换将影响数据库运行性能。建议将日志切换频次设置为10分钟。因此数据复制最大延迟约为10分钟。源端CPU占用小于10％知足，对主系统资源消耗极小。小于1%业务高目标端CPU占用小于10％知足，对目标资源消耗极小。小于5%不知足。在最大性能模式下，物理峰期对DataGuard在日志切换后将改变的数系统的据写入灾备中心。频繁的日志切换将影响复制数据延迟平均值10s以内影响数据库运行性能。建议将日志切换频次设置为10分钟。因此数据复制最大延迟约为10分钟。3.5.5数据一致性要求数据库复制软件提供数据库初始化同步、数据恢复后以及平时的数据一致性检查方案，要求方案中详尽注明该数据一致性比对方案的特点以及操作复杂度，并可知足如下要求：可在应用不停机的情况下，查找和发现不一致的数据；一致性检查需要能够进行对象属性、记录条数和记录的字段内容进行一致性检查；提供全库的记录级一致性检查时间（以100GB的数据为例）。支持不含PK/UK字段的表的一致性检查和修复。请提供在没有PK/UK字段的表中有1000万条记录的比对时间。关于不一致的数据，需要提供不一致记录详尽信息，以便进行精准的修复，同时提供数据修复方案。数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。应答：知足。DataGuard实现的基根源理既：经过备份恢复的基根源理保持灾备数据库与主数据库的一致。只有主数据库能够改正，备数据库是不能够做任何变动的。当系统发生Switchover的切换此后，主备关系变化，同样只有主数据库（原来的备数据库）能够改正，备数据库（原来的主数据库）是不能够改正的。因此太极计算机股份有限公司DataGuard不存在查找和发现不一致的数据的问题。如果备数据库做了相应改正，那么数据复制的基础被打破，数据复制将无法持续进行，需要从头建立灾备中心数据库系统。3.5.6系统兼容性数据库复制软件应支持以下操作系统平台：SunSolaris9,10IBMAIX5.x数据库复制软件应支持Oracle9i，Oracle10g，Oracle11g及后续数据库版本；支持异构平台，源端和目标端不同数据库版本；支持Cluster/HACMP和RAC模式，并支持不同操作系统下不同数据库版本之间的复制。应答：部分知足。DataGuard支持SunSolaris9,10以及IBMAIX5.xDataGuard支持Oracle9i，Oracle10g，Oracle11g及后续数据库版本；支持Cluster/HACMP和RAC模式。不支持异构平台，不支持源端和目标端不同数据库版本，不支持不同操作系统下不同数据库版本之间的复制。3.5.7高可用性主系统和备用系统的数据库处于双活状态，以保证在灾难发生前可在两个系统上运行不同种类的应用程序。应答：部分知足。物理DataGuard在正常恢复的时候无法处于翻开状态，在翻开的状态下无法处于恢复与主数据库保持一致的状态。本系统的RPO<15分钟，RTO<6小时，每日归档日志产生量<20G。能够考虑以下方式解决该问题：如果用户对容灾数据库使用时间为白天，那么在白天，将数据库启动为只读翻开模式，供业务查问。夜间，将数据库启动为恢复模式，保持与主生产中心一致。如果用户对容灾数据库使用时间为夜间，那么反之在夜间将数据库翻开只读，白天数据库做恢复。容灾中心数据库只在指准时间内对数据库做恢复，因此该数据库与主数据太极计算机股份有限公司库之间存在1天的数据差别。虽然没有实时做数据恢复，归档日志文件在产生后会同步写入容灾中心，因此系统能够知足RPO<15分钟的要求。当出现需要启动备用中心的情况，备用中心需要先经过归档日志文件恢复数据。目前每日归档日志量<20G，系统使用这些归档日志恢复数据的时间<2小时，能够知足RTO<6小时的业务需求。如果用户对容灾中心数据库使用为全天24小时，目前版本DataGuard无法知足要求，在Oracle11G此后的版本提供该功能。数据库复制软件应支持本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可经过Cluster软件接收到其余节点。应答：知足。数据库复制软件应本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可经过Cluster软件接收到其余节点。3.5.8强健性要求数据库复制软件在各样大压力和各样故障情况下不会造成数据复制失败。网络故障：长时间中止、短时间中止及网络断断续续情况下的正常复制；数据库故障：在目标端数据库故障下，源端数据库不能受到影响。当目标端数据库修复后，复制软件持续工作；服务器硬件故障：在目标端服务器故障下，源端生产系统不能受到影响，当目标端修复后，复制软件持续工作。应答：知足。物理DataGuard的最大性能模式下灾备中心服务器硬件、数据库故障以及网络故障均不会影响主中心的正常运行。如果主数据库与备用数据库之间的连结丢掉（比如，由于网络问题、灾备数据库问题、灾备服务器问题），则在主数据库上生成的重做数据将无法发送到那些备用数据库上。一旦从头成立连结，DataGuard就自动检测丢掉的存档日志序列（或间隔），并将必要的存档日志自动传输到备用数据库中。备用数据库将从头与主数据库同步，而无需管理员的任何手动干涉。3.5.9设施无关性独立于任何硬件设施、操作系统和Oracle数据库的不同版本，能够实现不太极计算机股份有限公司同平台之间数据库的复制。应答：不知足。DataGuard要求主备中心硬件架构相同，数据库版本完全一致。目前本系统中主备中心能够知足DataGuard的硬件及数据库版本要求。3.5.10管理监控功能数据库复制软件需提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时拥有完整方便的报警及追踪体制，方便故障的快速定位和解决。应答：知足。DataGuardBroker与OEM能够提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时拥有完整方便的报警及追踪体制，方便故障的快速定位和解决。第四章OracleDataGuard10gR2观点和理论分类：理论知识2012-12-1718:49785人阅读评论(0)收藏检举网上好多文章都只是介绍怎样搭建OracleDataGuard，可是很少有介绍到基本的观点和理论知识。同时官方文档是纯英文的，关于英文不好的读起来是特别难过。本人因为是英文专业，联合官方文档和自己所学，整理了以下这些文字，和大家一同共同学习。同时感谢谢永生（Warehouse）和OCM群中的其他兄弟们，并以此文件给口香糖同学新出生的儿子。1．OracleDataGuard介绍：OracleDataGuard是Oracle数据库高可用技术中的一种，经过数据冗余为公司级数据库提供高可用，数据保护和灾难恢复。DataGuard经过日志同步体制，在主备库之间实现数据同步，由于相互之间是经过网络连结，所以每个库能够放置在不同的地理地点，只需保证太极计算机股份有限公司网络连结通畅即可。如果主库发生计划中或许异样停机，DataGuard能够将任何1台Standby数据库切换成Primary数据库持续提供服务。1.1.Primary数据库：DataGuard配置中包含1台生产数据库，这台数据库能够是单实例也能够是负责对外提供大多数服务，在DataGuard中这台的角色就是Primary。RAC集群，1.2.Standby数据库：在一套DataGuard中最多能够有9台Standby数据库，Primary数据库经过网络将日志传输到Standby数据库，然后Standby在接收完日志后进行应用，以实现主备库之间的数据同步和事务一致性。和Primary数据库同样，Standby数据库也能够是单实例或许RAC集群。根据RedoLog的应用方式不同，Standby数据库又能够分为物理Standby和逻辑Standby。此外DataGuard是经过控制文件来辨别Primary和Standby数据库的，所以Standby数据库的控制文件一定不能用操作系统复制，一定要经过命令ALTERDATABASECREATESTANDBYCONTROLFILEAS来进行创立。1.2.1.物理Standby：物理Standby使用的是MediaRecovery技术，经过RedoApply，使用从主库接收到的RedoLog进行恢复，是鉴于block级的恢复，所以主备库中所有的schema都是完全同样的。物理Standby必须在mount阶段才能进行恢复，可是能经过只读方式翻开，在本中如果以只读方式翻开的话就无法进行恢复操作。所以在某些情况下，Standby一部分查问和备份的压力，可是DataGuard还不能作为性能优化的解决方案。10g版能够分担1.2.2.逻辑Standby：逻辑Standby使用的是LogMiner技术，把RedoLog中的内容复原成SQL语句，经过SQLApply在备库履行SQL语句来实现数据同步。LogMiner不支持所有的数据种类，不支持太极计算机股份有限公司的种类能够在DBA_LOGSTDBY_UNSUPPORTED视图中进行查察。逻辑Standby能够在恢复的同时进行写操作。1.3.DataGuard保护模式1.3.1.最大保护模式M