《OracleDataGuard容灾方案样本》由会员分享，可在线阅读，更多相关《OracleDataGuard容灾方案样本（79页珍藏版）》请在金锄头文库上搜索。
1、资料内容仅供您学习参考，如有不当之处，请联系改正或者删除。Oracle数据库异地容灾方案介绍 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第二章 Oracle Data Guard介绍122.1 Data Guard实现原理122.2 Oracle Data Guard 优势1
2、52.3 Data Guard提供的保护模式162.4 Data Guard实现方式以及对系统的限制要求172.5 切换方式17第三章 系统建议方案183.1 Data Guard优势183.2 Data Guard运行模式193.3 Data Guard保护模式193.4 Data Guard初始安装步骤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第一
3、章 需求分析1.1 序言在信息时代, 数据是企业创造商业价值的生产资料, 数据的丢失将为企业带来毁灭性的灾难。据Gartner Group的调查数据表明, 在经历过大型灾难或长时间系统停运的公司中, 有2/5的公司再也未恢复运行, 而在其余的公司中, 有1/3的公司在两年内破产。有句古谚叫”别把鸡蛋放在一个篮子里”。现在的信息系统, 各种数据高度集中, ”鸡蛋”全放在一个篮里了。一旦出现突然停电、 意外死机或者人为破坏, 造成数据丢失是不可避免的。面对各种未可预知的灾难, 越来越多的企业将容灾备份系统作为企业安全的保障。银联数据异地灾备项目的目标是保证SF25K上各银行( 民生银行贷记卡系统拟
4、迁移至IBM主机, 故此次灾备项目暂不考虑; 邮储银行贷记卡系统主机为IBM P570, 也不在考虑范围之内) 发卡系统的安全, 在灾难情况下, 最大限度地保护公司资产, 减少公司各方面的损失, 保证发卡系统的业务连续性。本方案仅对异地容灾数据库复制软件部分做相应阐述。1.2 用户现状1.2.1 系统平台发卡系统运行在一台SunFire E25K企业级服务器上, 经过两台Brocade SW4900 SAN交换机与两台企业级存储ST9990、 SE9970相连, 应用系统核心文件和数据库数据文件均存放在该存储上, 存储系统磁盘采用RAID 1+0方式。SF25K划分为四个物理分区( Domai
5、n) , 每家银行均使用其中的两个, 一个Domain作为生产主机, 另一个Domain作为热备主机。Domain操作系统为Solaris 10, 数据库系统为Oracle 10.2.0.2 RAC。经过Sun Cluster集群软件, 实现了生产机房内的双机热备份, 保证了系统的高可用性。另外, 在主机端还经过Sun MPXIO多通道负载均衡软件, 实现两条光纤通道的负载均衡, 进一步避免了单点故障。以下是发卡系统SAN架构图: SW4900 SW4900 SE9970 L180 (2 LTO-3)V280RNBU Master Server ST9990 SF25KDomain ADoma
6、in BDomain CDomain DVTL经过在主机端使用VxVM 4.1卷管理软件, 已建立了同机房数据灾备系统, 两台存储SE9970与ST9990之间实现了同步数据复制, 达到了以下灾难恢复目标: l 日常工作, 保证两台存储的数据实时同步保持一致, 所有数据不丢失。l 计划外停机, 任一台存储发生灾难, 保证数据不丢失, 即RPO=0, 并确保应用不中断运行, 即RTO=0。SE9970ST9990生产主机VxVM Mirror Volume1.2.2 数据库平台发卡系统中的数据库系统, 是整个生产系统中最关键、 最复杂的数据对象, 发卡系统的业务运转直接依赖于这些数据的可用性。为
7、了确保数据库的高可用性, 发卡系统数据库使用了Oracle 10g RAC版本10.2.0.2, 主、 备机两节点的数据库实例同时运行, 一旦主节点出现问题, 数据库实例无需启停, 可迅速将应用系统切换至备节点。截至到 8月底, 各数据库实例数据量情况见下表: 实例名总数据量( GB) Archive log数据量( GB) 高峰期Archive log变化量( MB/s) 平均每天最大帐单日HX25140.42 SZ15120.20 CR934.550.40 DE381.550.58 UC27512162.95 合计44620324.55 1.3 用户需求银联数据拟为提供外包服务的各银行发卡
8、系统建设异地灾备系统, 生产系统位于上海, 灾备系统位于北京。主备中心之间采用数据库复制软件进行异步数据复制, 以保证生产数据的安全性, 满足发卡系统的业务连续性需求。1.3.1 日常功能l 将生产中心发卡系统上的数据库变化实时异步复制到灾备中心; l 灾备中心的Oracle数据库处于打开状态, 可提供实时数据查询; l 对生产系统的资源占用不能太多, 不能影响到生产系统的正常运行; l 对网络带宽的占用较低。1.3.2 故障切换l 当生产中心的系统无法正常运行, 而又不能在短期内恢复时, 可利用灾备中心提供业务接管。 l 灾备中心必须在生产中心不可用6小时之内完成业务接管。l 当生产中心服务
9、器恢复正常后, 数据复制系统需要将灾备中心的最新数据反向复制回生产中心, 实现业务的恢复。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 数据复制过程可根据需要灵活地进行
10、控制或修改复制的方向, 以满足业务需求; l 支持在数据复制过程中对数据正确性进行校验, 如正在复制的数据在之前就已经不一致, 应提供报警功能, 以便及时发现错误, 避免错误的扩大; l 提供专用图形化集中管理软件。1.3.4 性能要求l 数据库初始化同步要求数据库复制软件能够将发卡系统的数据库中已有数据初始化同步到灾备中心数据库。在初始化同步过程中, 业务不能停止, 但可选择业务量较小时段进行。在解决方案书中要求详细描述初始化数据同步解决方案, 以及整个首次同步操作所需要的时间( 以100GB数据为标准) , 而且要求列出整个首次初始化过程中是否需要人为干预, 从而能够有效地评估整个首次数据
11、初始化的工作量。为了保证生产中心日后业务扩展存在更换服务器厂商以及数据库版本等情况, 需要注明是否支持异构平台下的首次数据初始化同步, 是否支持跨数据库版本之间数据库的初始化同步操作。l 数据复制性能指标数据复制的性能指标与系统平台、 网络带宽、 应用系统等因素密切相关, 参照下列运行环境: 项目配置数据源SF15K 24个CPU, 32GB内存, ORACLE 10.2.0.2 RAC目标端SF15K 24个CPU, 32GB内存, ORACLE 10.2.0.2总数据量500GB左右( 数据+索引) 每天的日志量每天20GB日志网络带宽100M和20M要求提供相应的性能参数指标: 类别指标
12、参考值首次数据初始化同步首次数据库初始化同步时间( 100M带宽) 小于10小时首次数据库初始化同步时间( 20M带宽) 小于48小时首次数据库初始化同步源端CPU占用小于30 增量数据同步( 单个复制链路) 源端CPU占用小于5目标端CPU占用小于5源端内存占用小于200M目标端内存占用小于200M复制数据延迟平均值10s以内业务高峰期对系统的影响 源端CPU占用小于10目标端CPU占用小于10复制数据延迟平均值10s以内1.3.5 数据一致性要求数据库复制软件提供数据库初始化同步、 数据恢复后以及日常的数据一致性检查方案, 要求方案中详细注明该数据一致性比对方案的特点以及操作复杂度, 并可
13、满足如下要求: l 可在应用不停机的情况下, 查找和发现不一致的数据; l 一致性检查需要能够进行对象属性、 记录条数和记录的字段内容进行一致性检查; l 提供全库的记录级一致性检查时间( 以100GB的数据为例) 。l 支持不含PK/UK字段的表的一致性检查和修复。请提供在没有PK/UK字段的表中有1000万条记录的比对时间。对于不一致的数据, 需要提供不一致记录详细信息, 以便进行精确的修复, 同时提供数据修复方案。数据修复工作要求操作简单, 修复速度快, 且修复过程中不影响业务正常运行。1.3.6 系统兼容性数据库复制软件应支持以下操作系统平台: l Sun Solaris 9,10l
14、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 管理监控功能数据库复制软件需提供统一的管理监控功能, 能实现对复制软件的运行状态、 运行日志、 系统配置等方面进行统一的管理及监控, 保证出现错误时具有完整
