OracleDataGuard容灾方案.docx
《OracleDataGuard容灾方案.docx》由会员分享，可在线阅读，更多相关《OracleDataGuard容灾方案.docx（22页珍藏版）》请在冰豆网上搜索。
OracleDataGuard容灾方案
Oracle数据库异地容灾方案介绍
2008年11月
第一章需求分析
一.1序言
在信息时代，数据是企业创造商业价值的生产资料，数据的丢失将为企业带来毁灭性的灾难。
据GartnerGroup的调查数据表明，在经历过大型灾难或长时间系统停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。
有句古谚叫“别把鸡蛋放在一个篮子里”。
现在的信息系统，各种数据高度集中，“鸡蛋”全放在一个篮里了。
一旦出现突然停电、意外死机或者人为破坏，造成数据丢失是不可避免的。
面对各种未可预知的灾难，越来越多的企业将容灾备份系统作为企业安全的保障。
银联数据异地灾备项目的目标是保证SF25K上各银行（民生银行贷记卡系统拟迁移至IBM主机，故此次灾备项目暂不考虑；邮储银行贷记卡系统主机为IBMP570，也不在考虑范围之内）发卡系统的安全，在灾难情况下，最大限度地保护公司资产，减少公司各方面的损失，保证发卡系统的业务连续性。
本方案仅对异地容灾数据库复制软件部分做相应阐述。
一.2用户现状
一.2.1系统平台
发卡系统运行在一台SunFireE25K企业级服务器上，通过两台BrocadeSW4900SAN交换机与两台企业级存储ST9990、SE9970相连，应用系统核心文件和数据库数据文件均存放在该存储上，存储系统磁盘采用RAID1+0方式。
SF25K划分为四个物理分区（Domain），每家银行均使用其中的两个，一个Domain作为生产主机，另一个Domain作为热备主机。
Domain操作系统为Solaris10，数据库系统为Oracle10.2.0.2RAC。
通过SunCluster集群软件，实现了生产机房内的双机热备份，保证了系统的高可用性。
此外，在主机端还通过SunMPXIO多通道负载均衡软件，实现两条光纤通道的负载均衡，进一步避免了单点故障。
以下是发卡系统SAN架构图：
SW4900
SW4900
SE9970
L180（2LTO-3）
V280R
NBUMasterServer
ST9990
SF25K
DomainA
DomainB
DomainC
DomainD
VTL
通过在主机端使用VxVM4.1卷管理软件，已建立了同机房数据灾备系统，两台存储SE9970与ST9990之间实现了同步数据复制，达到了以下灾难恢复目标：
●日常工作，保证两台存储的数据实时同步保持一致，所有数据不丢失。
●计划外停机，任一台存储发生灾难，保证数据不丢失，即RPO=0，并确保应用不中断运行，即RTO=0。
SE9970
ST9990
生产主机
VxVMMirrorVolume
一.2.2数据库平台
发卡系统中的数据库系统，是整个生产系统中最关键、最复杂的数据对象，发卡系统的业务运转直接依赖于这些数据的可用性。
为了确保数据库的高可用性，发卡系统数据库使用了Oracle10gRAC版本10.2.0.2，主、备机两节点的数据库实例同时运行，一旦主节点出现问题，数据库实例无需启停，可迅速将应用系统切换至备节点。
截至到2008年8月底，各数据库实例数据量情况见下表：
实例名
总数据量（GB）
Archivelog数据量（GB）
高峰期Archivelog变化量（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
一.3用户需求
银联数据拟为提供外包服务的各银行发卡系统建设异地灾备系统，生产系统位于上海，灾备系统位于北京。
主备中心之间采用数据库复制软件进行异步数据复制，以保证生产数据的安全性，满足发卡系统的业务连续性需求。
一.3.1日常功能
●将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；
●灾备中心的Oracle数据库处于打开状态，可提供实时数据查询；
●对生产系统的资源占用不能太多，不能影响到生产系统的正常运行；
●对网络带宽的占用较低。
一.3.2故障切换
●当生产中心的系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。
●灾备中心必须在生产中心不可用6小时之内完成业务接管。
●当生产中心服务器恢复正常后，数据复制系统需要将灾备中心的最新数据反向复制回生产中心，实现业务的恢复。
一.3.3基本要求
●复制软件应满足在单机或RAC环境下，对Oracle在线日志（Onlineredolog）的捕捉及复制；
●支持Oracle中所有的常用数据类型，如Oracle中的LONG、LONGRAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；
●支持对数据库中常用DDL操作的复制；
●支持事务复制，要求对数据库中较大的事务不会出现过多延迟；
●支持没有PK/UK字段的表的同步。
●数据复制过程可根据需要灵活地进行控制或修改复制的方向，以满足业务需求；
●支持在数据复制过程中对数据正确性进行校验，如正在复制的数据在之前就已经不一致，应提供报警功能，以便及时发现错误，避免错误的扩大；
●提供专用图形化集中管理软件。
一.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以内
一.3.5数据一致性
要求数据库复制软件提供数据库初始化同步、数据恢复后以及日常的数据一致性检查方案，要求方案中详细注明该数据一致性比对方案的特点以及操作复杂度，并可满足如下要求：
●可在应用不停机的情况下，查找和发现不一致的数据；
●一致性检查需要能够进行对象属性、记录条数和记录的字段内容进行一致性检查；
●提供全库的记录级一致性检查时间（以100GB的数据为例）。
●支持不含PK/UK字段的表的一致性检查和修复。
请提供在没有PK/UK字段的表中有1000万条记录的比对时间。
对于不一致的数据，需要提供不一致记录详细信息，以便进行精确的修复，同时提供数据修复方案。
数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。
一.3.6系统兼容性
数据库复制软件应支持以下操作系统平台：
●SunSolaris9,10
●IBMAIX5.x
数据库复制软件应支持Oracle9i，Oracle10g，Oracle11g及后续数据库版本；支持异构平台，源端和目标端不同数据库版本；支持Cluster/HACMP和RAC模式，并支持不同操作系统下不同数据库版本之间的复制。
一.3.7高可用性
主系统和备用系统的数据库处于双活状态，以保证在灾难发生前可在两个系统上运行不同类型的应用程序。
数据库复制软件应支持本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可通过Cluster软件接管到其它节点。
一.3.8健壮性要求
数据库复制软件在各种大压力和各种故障情况下不会造成数据复制失败。
●网络故障：
长时间中断、短时间中断及网络时断时续情况下的正常复制；
●数据库故障：
在目标端数据库故障下，源端数据库不能受到影响。
当目标端数据库修复后，复制软件继续工作；
●服务器硬件故障：
在目标端服务器故障下，源端生产系统不能受到影响，当目标端修复后，复制软件继续工作。
一.3.9设备无关性
独立于任何硬件设备、操作系统和Oracle数据库的不同版本，能够实现不同平台之间数据库的复制。
一.3.10管理监控功能
数据库复制软件需提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时具有完整方便的报警及跟踪机制，方便故障的快速定位和解决。
第二章OracleDataGuard介绍
容灾系统主要包括数据保护和应用切换两大方面，其中最为重要的是数据保护部分。
除了要将这些数据存放在高可用的存储设备上之外，最重要的是这些关键数据应该在异地之间保持一致，以使灾难发生后，系统可以尽快恢复。
下面是几种主要的数据保护技术。
实现数据的异地复制，有软件方式和硬件方式两种途径。
软件方式，是通过主机端软件来实现，如第三方软件或者数据库厂家提供的远程数据容灾工具来实现业务数据的远程复制。
硬件方式，是基于智能存储系统的控制器的远程拷贝，可以在主、备存储系统之间通过硬件实现复制。
在实际的容灾系统中，由于系统的环境不同，安全性要求不同以及采用的软硬件产品不同，数据复制过程中的工作机制也不尽相同。
概括地讲，数据复制地工作机制主要包括同步和异步两种。
同步远程镜像（同步复制技术）是指通过远程镜像软件，将本地数据以完全同步的方式复制到异地，每一本地的I/O事务均需等待远程复制的完成确认信息，方予以释放。
异步远程镜像（异步复制技术）保证在更新远程存储视图前完成向本地存储系统的基本I/O操作，而由本地存储系统提供给请求镜像主机的I/O操作完成确认信息，远程的数据复制以后台同步的方式进行。
因为带宽等因素限制，本次容灾方案仅包括了异步复制的方式的讨论。
二.1DataGuard实现原理
OracleDataGuard是当今保护企业核心资产（数据）的最有效解决方案，它能够使数据在24x7的基础上可用，而无论是否发生灾难或其它中断。
OracleDataGuard是管理、监控和自动化软件的基础架构，它创建、维护和监控一个或多个备用数据库，以保护企业数据结构不受故障、灾难、错误和崩溃的影响。
DataGuard使备用数据库保持为与生产数据库在事务上一致的副本。
这些备用数据库可能位于距生产数据中心数千公里的远程灾难恢复站点，或者可能位于同一城市、同一校园乃至同一建筑物内。
当生产
升级会员 