Oracle数据库异地容灾方案介绍
2008年11月

第一章 需求分析
一.1 序言
在信息时代，数据是企业创造商业价值的生产资料，数据的丢失将为企业带来毁灭性的灾难。据Gartner Group的调查数据表明，在经历过大型灾难或长时间系统停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。
有句古谚叫“别把鸡蛋放在一个篮子里”。现在的信息系统，各种数据高度集中，“鸡蛋”全放在一个篮里了。一旦出现突然停电、意外死机或者人为破坏，造成数据丢失是不可避免的。面对各种未可预知的灾难，越来越多的企业将容灾备份系统作为企业安全的保障。
银联数据异地灾备项目的目标是保证SF25K上各银行（民生银行贷记卡系统拟迁移至IBM主机，故此次灾备项目暂不考虑；邮储银行贷记卡系统主机为IBM P570，也不在考虑范围之内）发卡系统的安全，在灾难情况下，最大限度地保护公司资产，减少公司各方面的损失，保证发卡系统的业务连续性。
本方案仅对异地容灾数据库复制软件部分做相应阐述。
一.2 用户现状
一.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架构图：
通过在主机端使用VxVM 4.1卷管理软件，已建立了同机房数据灾备系统，两台存储SE9970与ST9990之间实现了同步数据复制，达到了以下灾难恢复目标：
oracle 时间转换日常工作，保证两台存储的数据实时同步保持一致，所有数据不丢失。
计划外停机，任一台存储发生灾难，保证数据不丢失，即RPO=0，并确保应用不中断运行，即RTO=0。
一.2.2数据库平台
发卡系统中的数据库系统，是整个生产系统中最关键、最复杂的数据对象，发卡系统的业务运转直接依赖于这些数据的可用性。
为了确保数据库的高可用性，发卡系统数据库使用了Oracle 10g RAC版本10.2.0.2，主、备机两节点的数据库实例同时运行，一旦主节点出现问题，数据库实例无需启停，可迅速将应用系统切换至备节点。
截至到2008年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
一.3 用户需求
银联数据拟为提供外包服务的各银行发卡系统建设异地灾备系统，生产系统位于上海，灾备系统位于北京。主备中心之间采用数据库复制软件进行异步数据复制，以保证生产数据的安全性，满足发卡系统的业务连续性需求。
一.3.1日常功能
将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；
灾备中心的Oracle数据库处于打开状态，可提供实时数据查询；
对生产系统的资源占用不能太多，不能影响到生产系统的正常运行；
对网络带宽的占用较低。
一.3.2故障切换
当生产中心的系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。
灾备中心必须在生产中心不可用6小时之内完成业务接管。
当生产中心服务器恢复正常后，数据复制系统需要将灾备中心的最新数据反向复制回生产中心，实现业务的恢复。
一.3.3基本要求
复制软件应满足在单机或RAC环境下，对Oracle在线日志(Online redo log)的捕捉及复制；
支持Oracle中所有的常用数据类型，如Oracle中的LONG 、LONG RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。