文档介绍：Oracle数据库异地容灾方案介绍
2008年11月
目录
第一章需求分析 4
4
4
4
6
7
7

Oracle数据库异地容灾方案介绍
2008年11月
目录
第一章需求分析 4
4
4
4
6
7
7
7
7
8
9
9
10
10
10
11
第二章OracleDataGuard介绍 12
12
15
16
17
17
第三章系统建议方案 18
18
19
19
19
20
20
21
22
23
24
25
25
26
27
27
需求分析
序文
在信息时代,数据是企业制造商业价值的消费材料,数据的丧失将为企业带来消灭性的灾难。据GartnerGroup的调查数据说明,在经历过大型灾难或长时间系统停运的公司中,有2/5的公司再也未恢复运转,而在其余的公司中,有1/3的公司在两年内破产。
有句古谚叫“别把鸡蛋放在一个篮子里”。如今的信息系统,各种数据高度集中,“鸡蛋”全放在一个篮里了。一旦出现忽然停电、意外死机或者人为破坏,造成数据丧失是不可防止的。面对各种未可预知的灾难,越来越多的企业将容灾备份系统作为企业平安的保障。
银联数据异地灾备工程的目的是保证SF25K上各银行(民生银行贷记卡系统拟迁移至IBM主机,故此次灾备工程暂不考虑;邮储银行贷记卡系统主机为IBMP570,也不在考虑范围之内)发卡系统的平安,在灾难情况下,最大限度地保护公司资产,减少公司各方面的损失,保证发卡系统的业务连续性。
本方案仅对异地容灾数据库复制软件部分做相应阐述。
用户现状
系统平台
发卡系统运转在一台SunFireE25K企业级效劳器上,通过两台BrocadeSW4900SAN交换机与两台企业级存储ST9990、SE9970相连,应用系统核心文件和数据库数据文件均存放在该存储上,
存储系统磁盘采纳RAID1+0方式。
SF25K划分为四个物理分区(Domain),每家银行均使用其中的两个,一个Domain作为消费主机,另一个Domain作为热备主机。Domain操作系统为Solaris10,。通过SunCluster集群软件,实现了消费机房内的双机热备份,保证了系统的高可用性。此外,在主机端还通过SunMPXIO多通道负载平衡软件,实现两条光纤通道的负载平衡,进一步防止了单点毛病。
以下是发卡系统SAN架构图:
SW4900
SW4900
SE9970
L180(2LTO-3)
V280R
NBUMasterServer
ST9990
SF25K
DomainA
DomainB
DomainC
DomainD
VTL
,已建立了同机房数据灾备系统,两台存储SE9970与ST9990之间实现了同步数据复制,到达了以下灾难恢复目的:
日常工作,保证两台存储的数据实时同步保持一致,所有数据不丧失。
计划外停机,任一台存储发生灾难,保证数据不丧失,即RPO=0,并确保应用不中断运转,即RTO=0。
SE9970
ST9990
消费主机
VxVMMirrorVolume
数据库平台
发卡系统中的数据库系统,是整个消费系统中最关键、最复杂的数据对象,发卡系统的业务运转直截了当依赖于这些数据的可用性。
为了确保数据库的高可用性,,主、备机两节点的数据库实例同时运转,一旦主节点