OracleDataGuard容灾专项方案.doc

Oracle数据库异地容灾方案介绍

11月
目录
第一章 需求分析 4
1.1 序言 4
1.2 用户现实状况 4
1.2.1 系统平台 4
1.2.2 数据库平台 6
1.3 用户需求 7
1.3.1 日常功效 7
1.3.2 故障切换 7
1.3.3 基础要求 7
1.3.4 性能要求 8
1.3.5 数据一致性 9
1.3.6 系统兼容性 9
1.3.7 高可用性 10
1.3.8 健壮性要求 10
1.3.9 设备无关性 10
1.3.10 管理监控功效 11
第二章 Oracle Data Guard介绍 12
2.1 Data Guard实现原理 12
2.2 Oracle Data Guard 优势 15
2.3 Data Guard提供保护模式 16
2.4 Data Guard实现方法和对系统限制要求 17
2.5 切换方法 17
第三章 系统提议方案 18
3.1 Data Guard优势 18
3.2 Data Guard运行模式 19
3.3 Data Guard保护模式 19
3.4 Data Guard初始安装步骤 19
3.5 用户需求点对点应答 20
3.5.1 日常功效 20
3.5.2 故障切换 21
3.5.3 基础要求 22
3.5.4 性能要求 23
3.5.5 数据一致性 24
3.5.6 系统兼容性 25
3.5.7 高可用性 25
3.5.8 健壮性要求 26
3.5.9 设备无关性 27
3.5.10 管理监控功效 27

第一章 需求分析
1.1 序言
在信息时代，数据是企业发明商业价值生产资料，数据丢失将为企业带来毁灭性灾难。据Gartner Group调查数据表明，在经历过大型灾难或长时间系统停运企业中，有2/5企业再也未恢复运行，而在其它企业中，有1/3企业在两年内破产。
有句古谚叫“别把鸡蛋放在一个篮子里”。现在信息系统，多种数据高度集中，“鸡蛋”全放在一个篮里了。一旦出现忽然停电、意外死机或人为破坏，造成数据丢失是不可避免。面对多种未可预知灾难，越来越多企业将容灾备份系统作为企业安全保障。
银联数据异地灾备项目标目标是确保SF25K上各银行（民生银行贷记卡系统拟迁移至IBM主机，故此次灾备项目暂不考虑；邮储银行贷记卡系统主机为IBM P570，也不在考虑范围之内）发卡系统安全，在灾难情况下，最大程度地保护企业资产，降低企业各方面损失，确保发卡系统业务连续性。
本方案仅对异地容灾数据库复制软件部分做对应叙述。
1.2 用户现实状况
1.2.1 系统平台
发卡系统运行在一台SunFire E25K企业级服务器上，经过两台Brocade SW4900 SAN交换机和两台企业级存放ST9990、SE9970相连，应用系统关键文件和数据库数据文件均存放在该存放上，存放系统磁盘采取RAID 1+0方法。
SF25K划分为四个物理分区（Domain），每家银行均使用其中两个，一个Domain作为生产主机，另一个Domain作为热备主机。Domain操作系统为Solaris 10，数据库系统为Oracle 10.2.0.2 RAC。经过Sun Cluster集群软件，实现了生产机房内双机热备份，确保了系统高可用性。另外，在主机端还经过Sun MPXIO多通道负载均衡软件，实现两条光纤通道负载均衡，深入避免了单点故障。
以下是发卡系统SAN架构图：

SW4900
SW4900
SE9970
L180 (2 LTO-3)
V280R
NBU Master Server
ST9990
SF25K
Domain A
Domain B
Domain C
Domain D
VTL

经过在主机端使用VxVM 4.1卷管理软件，已建立了同机房数据灾备系统，两台存放SE9970和ST9990之间实现了同时数据复制，达成了以下灾难恢复目标：
l 日常工作，确保两台存放数据实时同时保持一致，全部数据不丢失。
l 计划外停机，任一台存放发生灾难，确保数据不丢失，即RPO=0，并确保应用不中止运行，即RTO=0。
SE9970
ST9990
生产主机
VxVM Mirror Volume

1.2.2 数据库平台
发卡系统中数据库系统，是整个生产系统中最关键、最复杂数据对象，发卡系统业务运转直接依靠于这些数据可用性。
为了确保数据库高可用性，发卡系统数据库使用了Oracle 10g RAC版本10.2.0.2，主、备机两节点数据库实例同时运行，一旦主节点出现问题，数据库实例无需启停，可快速将应用系统切换至备节点。
截至到8月底，各数据库实例数据量情况见下表：
实例名
总数据量（GB）
Archive log数据量（GB）
高峰期Archive log改变量（MB/s）
平均天天
最大帐单日
HX
25
1
4
0.42
SZ
15
1
2
0.20
CR
93
4.5
5
0.40
DE
38
1.5
5
0.58
UC
275
12
16
2.95
累计
446
20
32
4.55

1.3 用户需求
银联数据拟为提供外包服务各银行发卡系统建设异地灾备系统，生产系统在上海，灾备系统在北京。主备中心之间采取数据库复制软件进行异步数据复制，以确保生产数据安全性，满足发卡系统业务连续性需求。
1.3.1 日常功效
l 将生产中心发卡系统上数据库改变实时异步复制到灾备中心；
l 灾备中心Oracle数据库处于打开状态，可提供实时数据查询；
l 对生产系统资源占用不能太多，不能影响到生产系统正常运行；
l 对网络带宽占用较低。
1.3.2 故障切换
l 当生产中心系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。
l 灾备中心必需在生产中心不可用6小时之内完成业务接管。
l 当生产中心服务器恢复正常后，数据复制系统需要将灾备中心最新数据反向复制回生产中心，实现业务恢复。
1.3.3 基础要求
l 复制软件应满足在单机或RAC环境下，对Oracle在线日志(Online redo log)捕捉及复制；
l 支持Oracle中全部常见数据类型，如Oracle中LONG 、LONG RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；
l 支持对数据库中常见DDL操作复制；
l 支持事务复制，要求对数据库中较大事务不会出现过多延迟；
l 支持没有PK/UK字段表同时。
l 数据复制过程可依据需要灵活地进行控制或修改复制方向，以满足业务需求；
l 支持在数据复制过程中对数据正确性进行校验，如正在复制数据在之前就已经不一致，应提供报警功效，方便立即发觉错误，避免错误扩大；
l 提供专用图形化集中管理软件。
1.3.4 性能要求
l 数据库初始化同时
要求数据库复制软件能够将发卡系统数据库中已经有数据初始化同时到灾备中心数据库。在初始化同时过程中，业务不能停止，但可选择业务量较小时段进行。在处理方案书中要求具体描述初始化数据同时处理方案，和整个首次同时操作所需要时间（以100GB数据为标准），而且要求列出整个首次初始化过程中是否需要人为干预，从而能够有效地评定整个首次数据初始化工作量。
为了确保生产中心以后业务扩展存在更换服务器厂商和数据库版本等情况，需要注明是否支持异构平台下首次数据初始化同时，是否支持跨数据库版本之间数据库初始化同时操作。
l 数据复制性能指标
数据复制性能指标和系统平台、网络带宽、应用系统等原因亲密相关，参考下列运行环境：
项目
配　　置
数据源
SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2 RAC
目标端
SF15K 24个CPU，32GB内存， ORACLE 10.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 数据一致性
要求数据库复制软件提供数据库初始化同时、数据恢复后和日常数据一致性检验方案，要求方案中具体注明该数据一致性比对方案特点和操作复杂度，并可满足以下要求：
l 可在应用不停机情况下，查找和发觉不一致数据；
l 一致性检验需要能够进行对象属性、统计条数和统计字段内容进行一致性检验；
l 提供全库统计级一致性检验时间（以100GB数据为例）。
l 支持不含PK/UK字段表一致性检验和修复。请提供在没有PK/UK字段表中有1000万条统计比对时间。
对于不一致数据，需要提供不一致统计具体信息，方便进行正确修复，同时提供数据修复方案。数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。
1.3.6 系统兼容性
数据库复制软件应支持以下操作系统平台：
l Sun Solaris 9,10
l IBM AIX 5.x
数据库复制软件应支持Oracle 9i，Oracle 10g，Oracle 11g及后续数据库版本；支持异构平台，源端和目标端不一样数据库版本；支持Cluster/HACMP和RAC模式，并支持不一样操作系统下不一样数据库版本之间复制。
1.3.7 高可用性
主系统和备用系统数据库处于双活状态，以确保在灾难发生前可在两个系统上运行不一样类型应用程序。
数据库复制软件应支持当地Cluster/HACMP高可用方法，在当地单节点出现故障时，可经过Cluster软件接管到其它节点。
1.3.8 健壮性要求
数据库复制软件在多种大压力和多种故障情况下不会造成数据复制失败。
l 网络故障：长时间中止、短时间中止及网络时断时续情况下正常复制；
l 数据库故障：在目标端数据库故障下， 源端数据库不能受到影响。当目标端数据库修复后，复制软件继续工作；
l 服务器硬件故障：在目标端服务器故障下， 源端生产系统不能受到影响，当目标端修复后，复制软件继续工作。
1.3.9 设备无关性
独立于任何硬件设备、操作系统和Oracle数据库不一样版本，能够实现不一样平台之间数据库复制。
1.3.10 管理监控功效
数据库复制软件需提供统一管理监控功效，能实现对复制软件运行状态、运行日志、系统配置等方面进行统一管理及监控，确保出现错误时含有完整方便报警及跟踪机制，方便故障快速定位和处理。

第二章 Oracle Data Guard介绍
容灾系统关键包含数据保护和应用切换两大方面，其中最为关键是数据保护部分。除了要将这些数据存放在高可用存放设备上之外，最关键是这些关键数据应该在异地之间保持一致，以使灾难发生后，系统能够立即恢复。下面是多个关键数据保护技术。
实现数据异地复制，有软件方法和硬件方法两种路径。软件方法，是经过主机端软件来实现，如第三方软件或数据库厂家提供远程数据容灾工具来实现业务数据远程复制。
硬件方法，是基于智能存放系统控制器远程拷贝，能够在主、备存放系统之间经过硬件实现复制。
在实际容灾系统中，因为系统环境不一样，安全性要求不一样和采取软硬件产品不一样，数据复制过程中工作机制也不尽相同。概括地讲，数据复制地工作机制关键包含同时和异步两种。同时远程镜像(同时复制技术)是指经过远程镜像软件，将当地数据以完全同时方法复制到异地，每一当地I/O事务均需等候远程复制完成确定信息，方给予释放。异步远程镜像(异步复制技术)确保在更新远程存放视图前完成向当地存放系统基础I/O操作，而由当地存放系统提供给请求镜像主机I/O操作完成确定信息，远程数据复制以后台同时方法进行。因为带宽等原因限制，此次容灾方案仅包含了异步复制方法讨论。
2.1 Data Guard实现原理
Oracle Data Guard 是当今保护企业关键资产（数据）最有效处理方案，它能够使数据在 24x7 基础上可用，而不管是否发生灾难或其它中止。
Oracle Data Guard 是管理、监控和自动化软件基础架构，它创建、维护和监控一个或多个备用数据库，以保护企业数据结构不受故障、灾难、错误和瓦解影响。
Data Guard 使备用数据库保持为和生产数据库在事务上一致副本。这些备用数据库可能在距生产数据中心数千公里远程灾难恢复站点，或可能在同一城市、同一校园乃至同一建筑物内。当生产数据库因为计划中止或意外中止而变得不可用时，Data Guard 能够将任意备用数据库切换到生产角色，从而使和中止相关停机时间减到最少，并预防任何数据丢失。
作为 Oracle 数据库企业版一个特征推出 Data Guard 能够和其它 Oracle 高可用性 (HA) 处理方案（如真正应用集群 (RAC) 和恢复管理器 (RMAN)）结合使用，以提供业内前所未有高水平数据保护和数据可用性。下图提供了 Oracle Data Guard 一个概述。

Oracle Data Guard 包含一个生产数据库，也称为主数据库，和一个或多个备用数据库，这些备用数据库是和主数据库在事务上一致副本。Data Guard 利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入当地重做日志文件中。经过 Data Guard，还将重做数据传输到备用站点上，并应用到备用数据库中，从而使备用数据库和主数据库保持同时。Data Guard 许可管理员选择将重做数据同时还是异步地发送到备用站点上。
备用数据库底层技术是 Data Guard 重做应用（物理备用数据库）和 Data Guard SQL 应用（逻辑备用数据库）。物理备用数据库在磁盘上拥有和主数据库逐块相同数据库结构，而且使用 Oracle 介质恢复进行更新。逻辑备用数据库是一个独立数据库，它和主数据库包含相同数据。它使用 SQL 语句进行更新，其相对优势是能够并行用于恢复和诸如报表、查询等其它任务。
Data Guard 简化了主数据库和选定备用数据库之间转换和故障切换，从而降低了由计划停机和计划外故障所造成总停机时间。
主数据库和备用数据库和它们多种交互能够使用 SQL*Plus 来进行管理。为了取得更简便可管理性，Data Guard 还提供了一个分布式管理框架（称为 Data Guard Broker），它不仅自动化了 Data Guard 配置创建、维护和监控，并对这些操作进行统一管理。管理员能够使用 Oracle Enterprise Manager 或 Broker 自己专用命令行界面 (DGMGRL) 来利用 Broker 管理功效。
下图显示了 Oracle Data Guard 组件。

2.2 Oracle Data Guard 优势
灾难恢复和高可用性 — Data Guard 提供了一个高效和全方面灾难恢复和高可用性处理方案。易于管理转换和故障切换功效许可主数据库和备用数据库之间角色转换，从而使主数据库因计划和计划外中止所造成停机时间减到最少。
完善数据保护 — 使用备用数据库，Data Guard 可确保即使碰到不可预见灾难也不会丢失数据。备用数据库提供了预防数据损坏和用户错误安全保护。主数据库上存放器级物理损坏不会传输到备用数据库上。一样，造成主数据库永久损坏逻辑损坏或用户错误也能够得四处理。最终，在将重做数据应用到备用数据库时会对其进行验证。
有效利用系统资源 — 备用数据库表使用从主数据库接收到重做数据进行更新，而且可用于诸如备份操作、报表、累计和查询等其它任务，从而降低实施这些任务所必需主数据库工作负载，节省宝贵 CPU 和 I/O 周期。使用逻辑备用数据库，用户能够在模式中不从主数据库进行更新表上实施数据处理操作。逻辑备用数据库能够在从主数据库中对表进行更新时保持打开，并可同时对表进行只读访问。最终，能够在维护表上创建额外索引和物化视图，以取得愈加好查询性能和适应特定业务要求。
灵活数据保护功效，从而在可用性和性能要求之间取得平衡 — Oracle Data Guard 提供了最大保护、最高可用性和最高性能等模式，来帮助企业在系统性能要求和数据保护之间取得平衡。
自动间隔检测及其处理方案 — 假如主数据库和一个或更多个备用数据库之间连接丢失（比如，因为网络问题），则在主数据库上生成重做数据将无法发送到那些备用数据库上。一旦重新建立连接，Data Guard 就自动检测丢失存档日志序列（或间隔），并将必需存档日志自动传输到备用数据库中。备用数据库将重新和主数据库同时，而无需管理员任何手动干预。
简单集中式管理 — Data Guard Broker 使一个 Data Guard 配置中多个数据库间管理和操作任务自动化。Broker 还监控单个 Data Guard 配置内全部系统。管理员能够使用 Oracle Enterprise Manager 或 Broker 自己专用命令行界面 (DGMGRL) 来利用这个集成管理框架。
和 Oracle 数据库集成 — Oracle Data Guard 是作为 Oracle 数据库（企业版）一个完全集成功效提供，无需任何额外费用。
2.3 Data Guard提供保护模式
Oracle针对用户不一样需求提供三种保护模式：最大保护模式、最大性能模式、最大可用模式。
Oracle提供Data Guard在最大保护模式下能够确保数据完全不丢失。它在写当地日志同时写远程standby数据库日志。只有两个日志均写成功后一个操作才是正式完成。这种方法确保了数据最大安全，能够确保主数据库损坏情况下没有任何数据丢失。但这种情况对主数据库性能有较大影响，即使在高速局域网内，最大保护模式也会对主数据库性能有超出10%性能影响。这种方法对主备两个数据库之间链路有很高要求。在这种保护模式下不管是网路链路还是standby数据库等发生故障造成日志无法正常写均会造成主数据库无法使用。所以只有在对数据安全要求最高情况下才会考虑使用这种方法。
Oracle也提供最大性能模式。这种模式下，不传输实时修改日志文件，传输是归档日志文件，所以对主数据库性能影响很小。归档日志文件传输是否能够成功对主数据库运行没有任何影响，所以在网络出现中止或standby数据库出现异常也不会影响主数据库正常运行。但因为日志没有同时写，所以在灾难发生时候备份数据库和主数据库可能有一定数据差异。
Oracle提供第三种模式是上述两种方法折中。在网络正常情况下它运行方法类似于最大保护模式，日志实时传输。当网络或standby出现故障时候它运行模式类似于最大性能模式，日志延迟传输，不会造成主数据库停止运行。这种方法在正常情况下因为日志实时传输，所以一样对主数据库性能有较大影响，而且对网络链路要求较高。
总而言之，不一样保护模式比较以下：

最大保护
最大可用
最大性能
对主数据库性能影响
较高
较高
低
对网络链路要求
极高
高
低
备份系统发生故障
主数据库不可用
无影响
无影响
数据保护
无数据丢失
基础无数据丢失
少许数据丢失
2.4 Data Guard实现方法和对系统限制要求
Oracle针对不一样用户情况提供两种不一样standby方法。物理standby ,逻辑standby。
物理standby数据库，在通常模式下备份库一直处于恢复状态，用户无法访问备份库数据。假如需要访问数据，需要将恢复模式停止，将数据库打开到只读状态。这两种状态是排它，也就是说数据库要么是恢复状态，保持和主数据库一致，在这种状态下数据库内容不可访问；要么是只读状态，数据库不会做恢复和主数据保持一致。
Oracle还提供逻辑standby数据库。这种方法下数据库能够在打开状态下保持和主数据库同时工作。这种打开状态和一般数据库open状态不一样，不能对数据做修改。这种方法通常见于繁忙系统，如主数据库日常完成业务处理，逻辑standby数据库在完成容灾同时分担主数据库查询统计工作。这么大大节省了系统资源。但这种方法对数据库有一定限制，并不是全部系统全部能够支持。部分较为特殊数据类型不支持，另外全部表必需要有主键或唯一性索引。
不管是物理standby 还是逻辑standby均对系统要求以下:
l 主备数据库必需是完全相同硬件架构，如均为SUN平台。机器内存大小、CPU数量主频能够不一样。
l 操作系统版本、补丁完全相同。
l 数据库版本完全相同。但RAC选件能够不一样。即主数据库能够是RAC模式，备份节点能够是单机。
2.5 切换方法
Oracle Data Guard能够实现failover 和switchover切换。
Switchover指有计划切换。如系统主数据库服务器需要硬件维护等有计划停机操作。这时候能够手工将全部日志和归档日志文件传输到备份节点后实施switchover切换。这种情况下等主数据库恢复正常后系统能够手工切换回来。
Failover切换是指系统出现了异常情况下切换。系统管理员发觉主数据库服务器无法提供服务，决定开启容灾系统。在这种情况下切换后假如主数据库服务器恢复正常后需要重新配置整个Data Guard环境，无法切换回主数据库服务器。
不管是那种切换方法，主备系统之间均存在部分差异。如IP地址不一样，需要修改服务器IP 地址或应用程序重新指向。因为在不一样局域网内，应用中间件需要跨防火墙访问系统。机器档次不一样、网络带宽不一样造成性能下降等问题。这需要在容灾预案中考虑。

第三章 系统提议方案
针对本容灾方案，我们推荐采取Oracle Data Guard技术。
3.1 Data Guard优势
l 节省投资
Oracle Data Guard是Oracle原厂自带容灾产品。该产品完全无偿。在容灾软件上用户无需支付额外费用，这能够大大节省用户资金投入。
l 技术成熟、稳定
早在Oracle 7版本就已经推出该功效（当初名称为Standby数据库）。其关键采取了Oracle成熟归档、备份、恢复技术。经过多年不停发展，已经成为一项技术成熟、稳定，有广泛成功案例技术。
l 对系统运行性能影响小
Data Guard在主数据库服务器端不存在对日志解析等工作，仅需要主数据库服务器端将归档日志文件传输到容灾节点。所以对生产系统性能影响极小。
l 能够满足用户基础业务需求
Data Guard能够满足用户基础数据容灾、RTO、RPO、带宽等相关基础业务需求。
3.2 Data Guard运行模式
Oracle提供了物理Data Guard和逻辑Data Guard两种不一样方法。这两种方法各有优缺点。因为用户数据库中存在大量表，这些表没有PK/UK；所以无法满足逻辑Data Guard使用前提条件。在本方案中，我们推荐采取物理Data Guard方法。
3.3 Data Guard保护模式
依据用户实际情况，在主数据库服务器和容灾数据库服务器之间距离较远，使用最大保护模式和最大可用模式均会严重影响主数据库运行性能。用户许可在出现异常情况下15分钟内数据丢失量，所以采取最大性能模式能够在现有带宽情况下满足用户容灾需求。
采取最大性能模式，系统不会实时传输日志文件，传输是归档日志文件，所以对主数据库性能影响很小。归档日志文件传输是否能够成功对主数据库运行没有任何影响，所以在网络出现中止或standby数据库出现异常也不会影响主数据库正常运行。但因为日志没有同时写，所以在灾难发生时候备份数据库和主数据库可能有一定数据差异。
3.4 Data Guard初始安装步骤
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、配置主、备中心数据库服务器Data Guard环境
该操作对主数据库运行没有任何影响。
其中灾备中心数据库平台要求和主中心架构一致，如均为SUN小型机。操作系统版本及数据库版本均需要一致。
Data Guard不支持异构平台数据容灾，也不支持不一样数据库版本之间做数据容灾。
6、使用主中心备份文件创建灾备中心数据库系统。
该操作关键是解压文件、恢复数据文件时间。约为2小时。
7、配置灾备中心环境。依据主中心归档日志保持灾备中心和主中心一致 。
3.5 用户需求点对点应答
3.5.1 日常功效
l 将生产中心发卡系统上数据库改变实时异步复制到灾备中心；
应答：满足。Data Guard经过归档日志将数据库改变复制到灾备中心。
l 灾备中心Oracle数据库处于打开状态，可提供实时数据查询；
应答：部分满足。物理Data Guard在正常恢复时候无法处于打开状态，在打开状态下无法处于恢复和主数据库保持一致状态。本系统RPO<15分钟，RTO<6小时，天天归档日志产生量<20G。能够考虑以下方法处理该问题：
假如用户对容灾数据库使用时间为白天，那么在白天，将数据库开启为只读打开模式，供业务查询。夜间，将数据库开启为恢复模式，保持和主生产中心一致。假如用户对容灾数据库使用时间为夜间，那么反之在夜间将数据库打开只读，白天数据库做恢复。
容灾中心数据库只在指定时间内对数据库做恢复，所以该数据库和主数据库之间存在1天数据差异。即使没有实时做数据恢复，归档日志文件在产生后会同时写入容灾中心，所以系统能够满足RPO<15分钟要求。当出现需要开启备用中心情况，备用中心需要先经过归档日志文件恢复数据。现在天天归档日志量<20G，系统使用这些归档日志恢复数据时间< 2小时，能够满足RTO<6小时业务需求。
假如用户对容灾中心数据库使用为全天二十四小时，现在版本Data Guard无法满足要求，在Oracle11G 以后版本提供该功效。
l 对生产系统资源占用不能太多，不能影响到生产系统正常运行；
应答：满足。采取物理Data Guard最大性能模式，生产中心主机仅需要在归档日志产生后将归档日志文件写入异地容灾中心，对生产系统资源占用极少，不影响生产系统正常运行。在网络出现故障或容灾中心出现故障时，不会影响到生产系统正常运行。
l 对网络带宽占用较低。
应答：满足。Data Guard传输内容数据改变产生归档日志文件。现在天天归档日志产生量为20G，那么传输量为20G/天。
3.5.2 故障切换
l 当生产中心系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。
应答：满足。灾备中心能够提供数据库服务器。
l 灾备中心必需在生产中心不可用6小时之内完成业务接管。
应答：满足。灾备中心能够在6小时内完成业务接管。
l 当生产中心服务器恢复正常后，数据复制系统需要将灾备中心最新数据反向复制回生产中心，实现业务恢复。
应答：部分满足。系统切换能够分为有计划停机和故障停机。
在有计划停机情况下，灾备中心数据库在启用时候，数据库内容保持和生产中心完全一致。在主中心操作完成后，能够经过简单命令，将灾备中心启用期间数据修改反向复制回生产中心，实现业务恢复。
在故障停机情况下，主中心可能有部分数据(<15分钟)还未传输到备份中心，在灾备中心启用时候，主、备之间数据已不一致。所以需要将全部数据重新传输回主中心才能实现业务恢复。
3.5.3 基础要求
l 复制软件应满足在单机或RAC环境下，对Oracle在线日志(Online redo log)捕捉及复制；
应答：满足。Data Guard经过对Online redo log产生归档文件复制来完成容灾。
l 支持Oracle中全部常见数据类型，如Oracle中LONG 、LONG RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；
应答：满足。物理Data Guard支持Oracle中全部常见数据类型
l 支持对数据库中常见DDL操作复制；
应答：满足。物理Data Guard支持Oracle中常见DDL操作复制。
l 支持事务复制，要求对数据库中较大事务不会出现过多延迟；
应答：满足。物理Data Guard支持事务复制。对较大事务不会出现过多延迟。
l 支持没有PK/UK字段表同时。
应答：满足。物理Data Guard支持没有PK/UK字段表同时。
l 数据复制过程可依据需要灵活地进行控制或修改复制方向，以满足业务需求；
应答：满足。Data Guard能够灵活地控制主、备节点swithover切换。
l 支持在数据复制过程中对数据正确性进行校验，如正在复制数据在之前就已经不一致，应提供报警功效，方便立即发觉错误，避免错误扩大；
应答：满足。物理Data Guard复制前提条件是主、备数据库保持一致，所以不会出现复制数据在之前已经不一致情况。
l 提供专用图形化集中管理软件。
应答：满足。Data Guard Broker和OEM能够提供很方便图形化集中管理。
3.5.4 性能要求
l 数据库初始化同时
要求数据库复制软件能够将发卡系统数据库中已经有数据初始化同时到灾备中心数据库。在初始化同时过程中，业务不能停止，但可选择业务量较小时段进行。在处理方案书中要求具体描述初始化数据同时处理方案，和整个首次同时操作所需要时间（以100GB数据为标准），而且要求列出整个首次初始化过程中是否需要人为干预，从而能够有效地评定整个首次数据初始化工作量。
为了确保生产中心以后业务扩展存在更换服务器厂商和数据库版本等情况，需要注明是否支持异构平台下首次数据初始化同时，是否支持跨数据库版本之间数据库初始化同时操作。
应答：满足。详见Data Guard初始安装步骤
l 数据复制性能指标
数据复制性能指标和系统平台、网络带宽、应用系统等原因亲密相关，参考下列运行环境：
项目
配　　置
数据源
SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2 RAC
目标端
SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2
总数据量
500GB左右（数据+索引）
天天日志量
天天20GB日志
网络带宽
100M和20M
要求提供对应性能参数指标：
类别
指标
参考值
应答
首次数据初始化同时
首次数据库初始化同时时间（100M带宽）
小于10小时
满足，首次初始化同时时间小于5小时
首次数据库初始化同时时间（20M带宽）
小于48小时
满足，首次初始化同时时间小于12小时
首次数据库初始化同时源端CPU占用
小于30％
满足，对主系统资源消耗极小。小于1%
增量数据同时
（单个复制链路）
源端CPU占用
小于5％
满足，对主系统资源消耗极小。小于1%
目标端CPU占用
小于5％
满足，对目标资源消耗极小。小于5%
源端内存占用
小于200M
满足，对主资源消耗极小。无需额外内存消耗
目标端内存占用
小于200M
满足，对主资源消耗极小。无需额外内存消耗
复制数据延迟平均值
10s以内
不满足。在最大性能模式下，物理Data Guard在日志切换后将改变数据写入灾备中心。频繁日志切换将影响数据库运行性能。提议将日志切换频率设置为10分钟。所以数据复制最大延迟约为10分钟。
业务高峰期对系统影响
源端CPU占用
小于10％
满足，对主系统资源消耗极小。小于1%
目标端CPU占用
小于10％
满足，对目标资源消耗极小。小于5%
复制数据延迟平均值
10s以内
不满足。在最大性能模式下，物理Data Guard在日志切换后将改变数据写入灾备中心。频繁日志切换将影响数据库运行性能。提议将日志切换频率设置为10分钟。所以数据复制最大延迟约为10分钟。
3.5.5 数据一致性
要求数据库复制软件提供数据库初始化同时、数据恢复后和日常数据一致性检验方案，要求方案中具体注明该数据一致性比对方案特点和操作复杂度，并可满足以下要求：
l 可在应用不停机情况下，查找和发觉不一致数据；
l 一致性检验需要能够进行对象属性、统计条数和统计字段内容进行一致性检验；
l 提供全库统计级一致性检验时间（以100GB数据为例）。
l 支持不含PK/UK字段表一致性检验和修复。请提供在没有PK/UK字段表中有1000万条统计比对时间。
对于不一致数据，需要提供不一致统计具体信息，方便进行正确修复，同时提供数据修复方案。数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。
应答：满足。Data Guard实现基础原理既：经过备份恢复基础原理保持灾备数据库和主数据库一致。只有主数据库能够修改，备数据库是不能够做任何改动。当系统发生Switchover切换以后，主备关系改变，一样只有主数据库（原来备数据库）能够修改，备数据库（原来主数据库）是不能够修改。所以Data Guard不存在查找和发觉不一致数据问题。假如备数据库做了对应修改，那么数据复制基础被打破，数据复制将无法继续进行，需要重新构建灾备中心数据库系统。
3.5.6 系统兼容性
数据库复制软件应支持以下操作系统平台：
l Sun Solaris 9,10
l IBM AIX 5.x
数据库复制软件应支持Oracle 9i，Oracle 10g，Oracle 11g及后续数据库版本；支持异构平台，源端和目标端不一样数据库版本；支持Cluster/HACMP和RAC模式，并支持不一样操作系统下不一样数据库版本之间复制。
应答：部分满足。
Data Guard支持Sun Solaris 9,10和IBM AIX 5.x
Data Guard 支持Oracle 9i，Oracle 10g，Oracle 11g及后续数据库版本；支持Cluster/HACMP和RAC模式。
不支持异构平台，不支持源端和目标端不一样数据库版本，不支持不一样操作系统下不一样数据库版本之间复制。
3.5.7 高可用性
主系统和备用系统数据库处于双活状态，以确保在灾难发生前可在两个