DSG在国内的众多应用案例和客户列表
1 DSG在国内的主要应用客户
ü 中国电信：电信总部、北方电信9省、江苏电信、浙江电信、重庆电信、江西电信、广西电信、xinjiang电信、青海电信、海南电信、贵州电信、甘肃电信、宁夏电信、福建电信、成都电信；
ü 中国移动：江西移动、广西移动、甘肃移动、xinjiang移动、青海移动；
ü 中国网通：辽宁网通、周口通信、沧州通信；
ü 中国联通：广东联通、江苏联通、天津联通、辽宁联通、山东联通、陕西联通、四川联通、河北联通、重庆联通、吉林联通；
ü 证券行业：银河证券、华泰证券、长江证券、国联证券、民族证券、金通证券；
ü 政府机构：河北省地方税务局、xinjiang电力、上海市松江区财政局、广州公安、广西公安、杭州电力、东莞社保、江汉油田、辽宁交通厅、济南钢铁总公司等
ü 军队及其它：海军某部、火箭研究院、陆军某部、信息产业部（含浙江、江苏、陕西、黑龙江、福建、江西、甘肃、吉林、宁夏和重庆等信产部直属机构）；
2 DSG在类似项目的成功范例和相关经验
2.1 成功案例的列表
DSG从2002年在中国成立以来，在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。DSG始终以“客户需求为导向”的原则发展自己的产品，到目前为止，DSGRealSync产品已经在电信、政府、政券和企业采用，主要包括：
Realsync数据复制容灾软件目前占到国内市场份额的70%，客户包括：
● 电信行业：
北京移动、广西移动、甘肃移动、贵州移动、青海移动、广西电信、陕西电信、贵州电信、四川电信、安徽电信、海南电信、福建电信、甘肃电信、宁夏电信、广东电信、杭州电信、舟山电信、绍兴电信、湖州电信、辽宁网通、山东联通、江西联通、福建联通、广西联通、湖南联通、江苏联通、四川联通、广东联通、贵州联通、湖北联通、内蒙联通、贵州联通、云南联通…
● 金融行业：
广发银行、中国期货保证金监控中心、太平洋保险集团、中国金融期货交易所、华夏基金、易方达基金、招商基金、南方基金、鲁证期货、中银期货、东吴期货、国泰君安期货、中大期货、银河证券、民族证券、宏源证券、新时代证券、上海证券、远东证券、太平洋证券、东兴证券、万联证券、金元证券、信达证券、江南证券、华泰证券、南京证券、信泰证券、东吴证券、长江证券、国联证券、东海证券、西南证券、山西证券、金通证券、中原证券、财达证券、西部证券、国盛证券、国海证券、华福证券、恒泰证券、湘财证券、华鑫证券、财富证券、中天证券、财通证券、中投证券…
● 政府行业：
北京电力、青海电力、四川电力、江西电力、湖南电力、宁夏电力、天富热电、厦门电力、河北省地税、武汉财政、上海松江财政、吉林省交通厅 、辽宁省征稽局、蛇口码头、宁波港、贵州公安、东营公安、深圳交警、青岛有线、泰州社保、中国邮政、长春一汽、济南钢铁、深圳神州通集团、阿里巴巴、河北省地税11地市征管数据集中容灾备份系统、江西省电力12地市营销数据集中容灾备份…
这些系统都为DSG RealSync的实施积累了宝贵的经验。
2.2 成功案例的概况
|
序号 |
客户名称 |
实施日期 |
系统情况及需求 |
实施后情况 |
|
1 |
长江证券股份有限公司 |
2004.12.31 |
系统环境：集中交易系统分布在两台HP安腾服务器上，服务器分别配备4CPU和8G内存。数据库版本为Oracle9i，组成RAC。数据量为100GB左右，每天日志量为10-20GB左右。异地网络链路2M。 应用需求：1.本地数据库复制一份Oracle数据库副本，实现本地数据查询，业务分担以及本地业务接管功能；2.异地容灾通过窄带宽链路将数据复制到上海灾备中心提供异地容灾功能； |
1.满足设计方案的目标，实现1:2的容灾复制模式； 2.本地数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.低带宽情况能够保证数据复制传输的应用要求； 4.异地容灾系统演练成功； |
|
2 |
华泰证券股份有限公司 |
2006.02.15 |
系统环境：集中交易系统分布在两台IBM S80服务器上。数据库版本为Oracle9i，组成RAC。数据量为80GB左右，每天日志量为10-20GB左右。异地网络链路2M。 应用需求：异地容灾通过窄带宽链路将数据复制到异地灾备中心提供异地容灾功能； |
1.满足设计方案的目标，实现1:1的容灾复制模式； 2.低带宽情况能够保证数据复制传输的应用要求； 3.异地容灾系统演练成功； |
|
3 |
中国移动通信集团广西公司 |
2005.12.30 |
系统环境：营业数据库布放在两台IBM P690服务器上，数据量有1.1TB左右；客服数据库布放在另外一套HA环境下，数据量有100GB左右。数据库版本为Oracle9i，组成RAC。每天日志量为300GB左右，出账高峰期每天日志量达到600GB左右。本地网络链路1000M。应用需求：1.将两个应用数据库数据复制到1个Oracle数据库副本中，实现本地数据查询系统优化部署、业务负载分担等功能；2.提高容灾系统接管成功率，保证100%的业务连续性要求； |
1.满足设计方案的目标，实现2:1的容灾复制模式； 2.集中数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.利用数据库副本Open机制，保证容灾切换可靠性，提供100%的容灾切换支持； 4.应急容灾系统演练成功； |
|
4 |
河北省地方税务局信息中心 |
2005.12.27 |
系统环境：11个地市税务征管系统布放在两台IBM服务器上，组成HA双机环境。地市税务征管系统数据量有50GB左右；数据库版本为Oracle9i，异地网络链路2M。 应用需求：1.将11个地市税务征管数据库数据分别复制各本地1个Oracle数据库副本中，实现本地数据查询系统优化部署、业务负载分担等功能；2.将11地市税务征管数据库数据复制到省中心1个Oracle数据库副本，作为全省税务征管系统的集中容灾系统；3.省中心Oracle容灾数据库可为数据仓库提供数据抽取功能。 |
1.满足设计方案的目标，实现11:1:1的容灾复制模式； 2.本地数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.全省税务征管系统集中容灾的目标实现； 4.低带宽情况能够保证数据复制传输的应用要求； 5.省中心Oracle集中容灾数据库能够为数据仓库提供数据来源，满足数据抽取功能； 6.异地容灾系统业务接管及数据修复成功； |
|
5 |
江西省电力公司 |
2007.12.18 |
系统环境：12个地市电力营销系统布放在两台HP安腾服务器上，组成高可用架构。地市电力营销系统数据量有10-50GB左右；数据库版本为Oracle9i，异地网络链路100M（2M冗余）。 应用需求：1.将12地市电力营销数据库数据复制到省中心1个Oracle数据库副本，作为全省电力营销系统的集中容灾系统；2.省中心Oracle集中容灾数据库提供决策分析、网上营业厅、监控中心和查询系统的应用功能； |
1.满足设计方案的目标，实现12:1的容灾复制模式； 2.省中心容灾数据库副本实现查询应用功能，提高主应用的处理能力，客户满意度上升； 3.全省电力营销系统集中容灾的目标实现； 4.低带宽情况能够保证数据复制传输的应用要求； 5.异地容灾系统业务接管及数据修复成功； |
|
6 |
中国电信股份有限公司福建分公司 |
2006.12.14 |
系统环境：计费数据库布放在两台IBM P595服务器上，14CPU，数据量有2.2TB左右；统计数据库布放在另外两台IBM P595服务器上，数据量有1.5TB左右。数据库版本为Oracle9i，组成RAC。每天日志量各为110GB左右，本地网络链路1000M。 应用需求：1.将两个应用数据库数据复制到1个Oracle数据库副本中，实现本地数据查询系统优化部署、业务负载分担等功能；2.提供24个月的话单数据保存和对外查询业务； |
1.满足设计方案的目标，实现2:1的容灾复制模式； 2.集中数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； |
|
7 |
上海市松江区财政 |
2005.10.12 |
系统环境：国库支付数据库布放在两台IBM 服务器上，数据量80GB左右；数据库版本为Oracle8i，组成RAC。异地网络链路100M。 应用需求：1.将区属所有机关单位的财政数据复制到财政数据中心的1个Oracle数据库副本，作为国库支付系统的集中容灾；2.一期将三个应用数据库数据复制到1个Oracle数据库副本中，实现容灾和数据仓库抽取等功能； |
1.满足一期设计方案的目标，实现3:1的容灾复制模式； 2.国库支付系统财政数据集中容灾的目标实现； 3.低带宽情况能够保证数据复制传输的应用要求； 5.Oracle集中容灾数据库能够为数据仓库提供数据来源，满足数据抽取功能； 6.集中容灾系统业务接管演习及数据修复成功； |
|
8 |
中国联通有限公司湖北分公司 |
2007.03.19 |
系统环境：营业、账务和入库数据库布放在四台IBM P690服务器上，每台服务器22CUP、18GB内存，配置成集群。每个数据库数据量分别有800GB-1.4TB左右。数据库版本为Oracle10g，组成RAC。每天日志量为300GB左右。本地网络链路1000M。 应用需求：将三个应用数据库数据复制到本地1个Oracle数据库副本中，实现本地数据查询系统优化部署、业务负载分担等功能； |
1.满足设计方案的目标，实现3:1的容灾复制模式； 2.集中数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； |
|
9 |
中国网通（集团）有限公司辽宁省分公司 |
2004.03.11 |
系统环境：六大数据库各布放在两台IBM P690服务器上，总数据量有35TB左右。数据库版本为Oracle9i，分别组成RAC。本地网络链路1000M。 应用需求：1.将六大应用数据库数据复制到1个Oracle数据库副本中，实现本地数据整合，消除分散系统的信息孤岛；2.提供六大业务系统数据库关键数据的集中容灾，保证100%的业务连续性要求； |
1.满足设计方案的目标，实现6:1的容灾复制模式； 2.六大业务系统关键数据集中容灾的目标实现； 3.完成六大业务数据整合和优化过程； 4.集中容灾系统数据修复成功； |
|
10 |
中国联通有限公司福建分公司 |
2008.01.03 |
系统环境：营业和计费数据库布放在四台IBM P690服务器上，配置成高可用架构。每个数据库数据量分别有600GB-1.2TB左右。数据库版本为Oracle9i，组成RAC。每天日志量为150GB左右。本地网络链路1000M。 应用需求：将两个应用数据库数据复制到本地1个Oracle数据库副本中，实现本地数据查询系统优化部署、业务负载分担等功能； |
1.满足设计方案的目标，实现2:1的容灾复制模式； 2.集中数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； |
|
11 |
中国联通有限公司山东分公司 |
2008.02.19 |
系统环境：计费数据库各布放在四台HP RP8400服务器上，复制数据量有2TB左右。数据库版本为Oracle9i，分别组成RAC。本地网络链路1000M。 应用需求：1.将4个本地数据库复制一份Oracle数据库副本，实现本地数据查询，业务分担以及本地业务接管功能；2.对4个本地数据库的关键数据提供应急容灾功能； |
1.满足设计方案的目标，实现4:1的容灾复制模 式； 2.集中数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.利用数据库表级复制功能，对关键数据实现容灾保护； 4.Oracle容灾数据库数据恢复演练成功； |
|
13 |
深圳蛇口集装箱码头 |
2008.03.16 |
系统环境：生产数据库布放在Compaq的服务器上，操作系统为TRU64,8G内存的两台Compaq组成的RAC。数据库版本为Oracle10g，数据量为50GB。网络链路带宽为100M。 应用需求：1.实现关键生产数据库的数据容灾；2.提高容灾系统接管成功率，保证100%的业务连续性要求； |
1.满足设计方案的目标，实现1:1的容灾复制模式； 2.满足关键数据库的数据容灾要求； 3.异地容灾系统演练成功； |
|
14 |
中国电信股份有限公司贵州分公司 |
2008.04.07 |
系统环境：帐务数据库布放在HP-IA64 服务器上，26CPU/20G，配置成高可用架构。数据库版本为Oracle9.2.0.5，实际复制数据量为120GB左右； 97系统数据库布放在IBM服务器上， 28CPU/20G，数据库版本为Oracle9.2.0.5，实际复制数据量为280GB左右。本地网络链路1000M。 应用需求：1.将两个应用数据库关键数据表复制到目标数据库副本，实现本地数据查询，业务分担功能。2.替换现在已有的利用Oracle高级复制模式复制数据，减少对生产数据库的压力； |
1.满足设计方案的目标，实现2:1的容灾复制模式； 2.数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.完全替换Oracle高级复制，减少了生产端数据库的压力； 4.实现查询业务完全从生产库剥离，实现业务优化部署； |
|
15 |
东兴证券股份有限公司 |
2008.04.08 |
系统坏境：集中交易系统布放在两台HP580-G4服务器上，分别配备8CPU和32G内存。数据库版本为Oracle10g，组成RAC。数据量目前为100G左右。每天日志量为10-20GB左右。异地网络链路为4M。 |
1.满足设计方案的目标，实现1:2的容灾复制模式； 2.本地数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.低带宽情况能够保证数据复制传输的应用要求； 4.异地容灾系统演练成功； |
|
16 |
信达证券股份有限公司 |
2008.04.16 |
系统环境：集中交易数据库为Oracle10G RAC,布放在两台IBM P570上，配置成高可用架构。实际复制数据量有100GB左右，本地和同城灾备中心网络链路均为1000M。 应用需求：1.将集中交易数据库复制到同在证通机房的灾备中心数据库上，该数据库为Oracle10G主机为IBM P570，实现本地数据查询，业务分担以及本地业务接管功能；2.将集中交易数据库复制到同城的华侨城容灾机房，以适应同机房内出现灾难的情况，该灾备中心数据库为Oracle10G主机为IBM P570。 |
1.满足设计方案的目标，实现1:2的容灾复制模式； 2.本地数据库副本实现查询业务分担，提高主应用的处理能力和查询响应速度，客户满意度上升； 3.实现同城异地的容灾要求； |
2.3 广西移动营业和客服数据库数据复制应急查询平台
业务需求
将广西移动在白沙机房（BOSS1.5机房）新建一个基于SAN环境的计算机系统，有6个数据库(Oracle9i RAC)，其中的2个数据库（一个是Oracle 9iRAC，两个节点，另外一个是双机互备模式）根据业务需要分别复制到应急数据库（Oracle 9i Single）的2个实例，因此需采购相应的复制软件进行数据库的复制。
本工程是对其中的营业数据库和客服数据库进行复制，复制到应急数据库。
数据库复制系统的建立应实现将营业库和客服库的数据变化分别复制到应急库，使得应急营业库和应急客服库的数据和生产系统的营业库及客户库的数据同步。并能在生产系统的营业库或者客户库有故障时，替代故障库，接管应用。当故障库修复以后，能及时将应急库中的数据同步到修复后的生产数据库。
方案设计
根据广西移动数据复制系统的业务需求，采用DSG RealSync软件实现数据复制：系统总体结构如下图所示：
ü 生产系统
广西移动BOSS 1.5系统中需要本期工程进行复制的业务类型主要包括三种：
客服：系统的数据量约为100GB
帐务：系统的数据量约为800GB
营业：系统的数据量约为500GB
客服数据库单独运行，运行在两台IBM P690服务器上，组成RAC环境；
帐务和营业两个业务运行在一个ORACLE DATABASE的两个USER上，运行在两台IBM P690服务器上，组成RAC环境；
在容灾系统上安装两个ORACEL INSTANCE，运行两个ORACEL DATABASE。分别对应生产系统的客服数据库和营业帐务数据库中的两个用户。
性能参考
ü 全同步
DSG RealSync提供了不停机的首次全同步功能，该功能支持数据库在正常业务时间不中断的情况下进行全同步。避免了采用存储拷贝方式进行全同步时必需要求的业务中断。
对于广西移动的数据量，两个用户数据量约为800GB，采用10个并发任务进行全同步，同步时间共计约5小时左右。
ü 日志分析速度
系统每天处理的日志量达到400GB左右.
ü CPU资源速度
源端日志分析CPU占用量为单个CPU的10%，高峰期可达到单个CPU的60%.
解决方案特点
容灾与其他任何保险策略一样，当没有灾难出现时，我们根本无法意识到容灾系统所起到的作用，无法回收容灾系统建设所需的大量投资。但从系统安全性角度考虑，我们又必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。但是在大部分情况下，当未出现灾难时，我们的容灾端系统总是处于空闲状态，花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。
为此我们采用双active的结构，让容灾系统的数据库也处于OPEN状态，这样实际上广西移动就拥有了第二数据中心，而不仅仅是一个灾难备份系统，通过第二数据中心可以实现如下功能：
ü 核心业务的灾备平台
通过数据同步建立的第二数据中心可以实现对业务关键数据的容灾及保护，在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像，以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。
ü 业务负载分担
第二数据中心的数据处于实时可读取状态，数据库处于OPEN状态，实现BOSS系统业务模块的重新部署。
通过第二数据中心实现对BOSS核心系统的业务模块进行负载分担，将那些只对数据进行读取操作的模块都迁移到第二数据中心上来，主要包括：
ü 地市统计报表
ü 地市业务查询
ü 提供其他系统的数据访问接口；
这样作将达到两个好处：
ü 提高数据访问的效率，提高外围系统部署的灵活性；
ü 提高核心系统的运行效率，提高核心系统运行的稳定和可靠性；
2.4 福建电信的计费查询平台应用
本项目的建设需求是：为福建电信集中计费系统上线后，建立一个独立的查询系统，将计费数据库和统计数据库上的数据同步到一个正确的查询数据库中，通过该查询数据库实现24个月的计费话单数据保存、对外数据接口、以及对外查询业务。
系统方案
根据福建电信数据复制系统的业务需求，采用DSG RealSync软件将生产系统上的数据复制到历史查询系统上来。系统结构图为：
数据复制的数据源由计费数据库和统计数据库两个系统组成：
l Bill数据库（计费数据库）：
由两台IBM P595(14*2GHzcpu)组成，采用Oracle RAC模式；
话单数据库上的数据包括话单数据和统计数据：话单数据保存3+1月；
数据库大小容量为：2233.69434；
每天产生的Log日志量大约为122GB。
l Stat.数据库（统计数据库）：
由两台IBM P595组成，采用Oracle RAC模式；
存储长期的统计数据；
数据库大小计划容量为：1500GB；
每天产生的Log日志量计划为100GB左右。
l 查询服务器
采用IBM中高档UNIX服务器和高性能磁盘阵列，安装一个Oracle数据库系统。在数据库中创建两个User，一个User对应Billing数据库，一个User对应Stat.数据库。
主要性能和指标参数：
在数据同步过程中，DSG RealSync表现出了非常强劲的系统性能：
l 全同步性能：360GB/小时（46GB在440s全同步导出结束）；
l 实时同步性能：每天产生100GB的ArchiveLog情况下未出现日志分析和装载的延迟，完全能够跟得上系统的日志产生速度。
l CPU和内存资源占用：DSGRealSync在实时同步过程中的CPU占用<1%，内存占用大约在400M左右。
2.5 河北地税11地市本地复制和数据集中上收和容灾应用
业务需求
河北省地税税收业务系统目前采用了在各市局分散应用模式，即十一个市局分别有各自的数据中心，负责税务征管和帐务处理。
为了实现对关键业务数据的异地容灾备份，同时实现数据的省级集中用于决策支持系统的数据源，需要在省局建立各市局数据的准实时备份。
同时为了在各市局本地提供查询业务，要求复制到本地另一台服务器上一套税务征管数据用于查询。
首先进行数据上收到省中心，上收的目的在于：
l 提供数据备份：将11个市局和省直属局的业务数据同步到省局，作为各市局本地备份的补充，当市局数据发生破坏时，可通过省中心的备份数据进行恢复；
l 提供业务接管：当市局的业务系统有灾难发生而不能在规定的时间内恢复的时候，可以通过省中心的备用系统暂时接管该市局的关键业务，以保证业务的连续性为目的。
l 数据利用：11个市局和省直属局同步到省局的数据，将作为省中心的数据仓库系统的数据源。
同时，在市局本地再复制产生一套税收征管数据，用于本地数据查询和报表业务。
解决方案
每个市局由两台IBM服务器组成高可用性架构。系统各自运行一套ORACLE9i数据库。
数据上收系统是将11个地市征管数据库上的数据实时复制到省中心的集中数据库上，集中数据库起到备份、业务接管和数据利用三个目的。
2.6 长江证券集中交易系统灾备应用
1、业务需求：
长将证券从2004年开始着手全公司大集中交易系统建设工作。集中交易系统的目的是实现所属所有网点数据大集中，涵盖长江证券目前现有业务(AB股，基金、债券、三板、集合理财、银证通、多币种等)，整合并兼容长江证券即将开展的保险、期货等可预见金融业务的集中交易系统。是一套集金融产品研发、销售、管理为一体的信息系统。
随着证券集中交易系统的建设，对系统的安全性、可靠性和业务连续性方面提出了很高的要求。因为该系统是长江证券的业务得以正常运转的前提和保证。
而大量的意外事件，如不可抗自然灾难（地震、洪水）、意外灾难（火灾）、战争、恐怖事件（如911）、外界因素电网、通讯等处界因素、运营中心容错措施失效等原因都将会导致集中交易系统的数据丢失、业务中断，势必造成巨大的经济损失。
为此，长江证券提出了建设一套高效、可靠、投资回收比高的灾难备份系统。确保系统的数据安全和灾难发生时的快速恢复。
2、解决方案
DSG作为数据管理平台解决方案的提供商，推出了包括数据安全、数据共享和数据生命周期管理等在内的全套数据管理解决方案。
该解决方案中的数据库复制技术realsync正是为数据复制和备份提供了最佳的解决方案。该软件在工作组和企业级的关键应用的容灾支持上，能够提供比竞争对手更低成本、更高投资回报、结构更灵活、更容易实施和维护的容灾解决方案，提供对主流Linux和Unix等跨平台的Oracle数据库系统的复制和备份支持。
在大型企业和数据中心级的关键应用上，RealSync是完全满足数据中心级每秒数千条交易量的实时复制支持、减少数据丢失。同事通过处于打开（open）状态的备份数据库提供数据查询、统计报表等支持企业应用模块的重新部署。
为此，长江证券选择了DSGRealSYnc作为其交易系统的复制和备份解决方案：
系统结构：
如图所示，长江证券集中交易系统容灾备份实现如下目的：
（1） 本地复制：
将集中交易系统复制到局域网内部的系统上用于查询和本地业务接管功能；
（2） 远程异地复制：
将位于武汉的集中交易系统远程复制到上海证通灾备中心，广域网链路2M.
（3） 满足业务备份和恢复指标
要求灾难发生时数据丢量控制在最小范围之内，业务恢复事件缩短，减少对证券用户的交易影响。
支持平台：
数据库：oracle 9.2.0.4 RAC
操作系统：HP-UX
应用效果和特点：
总的说来，采用DSGRealSync数据复制和备份解决方案，非常适合长江证券的业务需求：
（1） 支持1:2的复制模式，满足一个数据源复制到多个目标数据库的业务需求
（2） 备份数据库出于打开状态，通过该打开数据库可用于分担集中交易系统的查询和统计等业务功能
（3） 支持异构模式的数据复制，支持数据源、目标数据库之间采用灵活的软件和硬件平台，而无需要求相同的操作系统和数据库版本
（4） 减少带宽占用，满足2M带宽的广域网复制需求
（5） 数据复制实时性好，数据复制频率可调整，复制周期可减少到秒级以内，减少数据丢失。
2.7 西北证券灾备一体化方案
西北某证券股份有限公司是经中国证券监督管理委员会批准设立，于2001年元月正式注册开业的证券经营机构，注册资本金壹拾亿元人民币，注册地为陕西省西安市，公司在上海设有投资管理、客户资产管理、投资银行、研发中心等业务部门，并在陕西、北京、上海、深圳、山东设立了22家证券营业部和14家证券服务部。
业务需求
西北某证券集中交易系统在2005年实现交易集中并升级到Linux + Oracle平台，系统稳定运行。2006年以来，随着中国股市转牛，交易活跃，系统所承受的压力越来越大。一旦集中交易系统出现故障，将导致严重的后果。因此，西北某证券考虑升级以往的应用级容灾系统，采用专业的灾备软件对集中交易系统进行完善的保护，包括:
1) 实现灾、备一体化的数据保护
对集中交易系统实现灾、备一体化保护，即在出现地震、火灾、存储故障、大面积电力中断、网络中断等情况下使用容灾系统实现业务快速接管；在出现诸如表数据丢失、数据逻辑错误、软件BUG等情况下可以通过备份系统快速在线修复系统。同时整合两种灾备模式，做到全方位保护。
2) 实现本、异地结合，查询、容灾结合的数据同步
在中心机房和异地机房之间各保留一份同步数据。中心机房的同步数据用于历史查询、数据分析等，作为“温备”数据。异地同步数据用于容灾切换，作为“灾备”数据。
3) 强调应急处理及演习体制的建设，实现灾备制度保证
在关键时刻容灾切换是否能够成功，不但取决于灾备软件，而且和平时的灾备演练、系统维护以及应急体制息息相关。因此，西北某证券要求灾备系统的建设同时应建设应急处理制度、演习制度并形成规范文档和应急指导手册，切实提高容灾系统的应用效果。
解决方案
根据西北某证券的实际情况，DSG采用RealSync+SnapAssure的灾备一体化方案来满足客户的需求。解决方案示意图如下:
如上图所示:
1) 配置两套DSGRealSync软件，分别实现从本地交易服务器组同步数据到中心机房的查询服务器以及异地机房的灾备服务器，实现本地和异地的数据同步；
2) 同步到中心机房的数据，用于历史查询、数据统计分析使用；同步到异地机房的数据，基本上不使用，作为容灾数据；数据同步实时进行，保持和交易系统一致。
3) 配置1套DSG SnapAssure软件，实现从交易服务器组到灾备服务器的异地备份。两地之间的网络为千兆单模光纤。
4) 备份到异地的集中交易系统数据，可以用来快速恢复或者在线修复系统。数据备份每个交易日执行一次，每次备份包括数据文件、日志文件、控制文件以及参数配置文件等。
5) 在项目实施中，分析系统可能遭遇的各种故障，根据故障情况判断故障等级和危害程度；分析两种灾备方式对不同故障的处理的优缺点，选择最优的处理方案，并写明详细的操作步骤，汇总成为应急手册。根据以上应急处理手册，进行日常的演习，通过平时的演练来促进系统故障时反应能力和故障处理能力。
应用效果
西北某证券的灾备一体化系统是我国证券行业内采用先进的灾备软件构建关键业务系统全方位数据保护的首例。该系统建成后，可以实现:
1) 大幅提高集中交易系统在各种故障情况下的安全性。解决方案针对系统可能遭遇到的存储故障、主机故障、数据库故障、文件丢失、日志文件丢失、表丢失、数据异常、大面积停电、网络中断、地震等灾难都制定了相应的处理措施，从而为可能发生的故障准备好了处理预案。和其他的容灾解决方案相比，本方案的措施更全面和具体，更有针对性，覆盖了单纯的容灾技术无法解决的逻辑故障问题这个技术死角，并且提供了更多的在线修复的手段，从而令客户在面对各种灾难是能够选择最合适的方案进行快速处理，把对系统的影响减小到最少。
2) 应急处理措施与技术手段融为一体。在本项目中，除了软硬件系统的安装配置，更多的精力被投入到针对具体故障情况下的切换、恢复以及修复等的处理和演练，从而将技术手段和处理故障的流程、机制等结合起来，从而为今后的系统维护、管理和应急处理铺平了道路。
3) 达到了更高的技术指标。测试表明，在通常的交易复制中，数据延迟时间为1-2秒；数据库的首次数据同步时间不超过20分钟，切换时间不超过5分钟；数据全库备份时间不超过半小时，增量备份时间数分钟，全库恢复时间11分钟。以上技术指标既表明了灾备软件平时运行的高效，也表明了故障情况下能够达到的处理能力。
2.8 湖北联通的复制应用
项目需求
湖北联通的综合营帐系统组成情况为：
主机设备: 采用4台IBM P690 小型机，每台小型机22CPU，18 GB内存，安装IBM AIX 5.2操作系统， 配置为集群。
存储设备: 采用EMC DMX 2000。
数据库 : 采用Oracle9i数据库，分别为营业、帐务和入库，3个数据库每库容量约800-1400GB。
解决方案
系统采用DSGRealSync软件将综合营帐等系统的数据分流一份到专门的系统，从该系统上实现地市查询、历史查询、数据抽取以及统计分析等功能。
系统采用一台IBM S85小型机和EMC Symmetrix 880磁盘阵列用作查询平台。
查询平台上采用Oracle 9i数据库，分别创建三个数据库实例，为营业、帐务和入库系统同步数据。
采用DSG RealSync系统以后，复制目标端系统处于正常的可用状态（称为“Active”），此时可以将一些只读业务，如地市查询、报表统计、历史数据查询、抽取数据、新系统测试等从主生产系统中迁移到查询系统上进行。这样，既能提高查询系统的利用率，又能减轻主生产系统的压力。
2.9 江苏联通业务复制应用
项目需求
江苏联通为满足其全省1200多万用户的业务量，实现话音和Internet业务的综合管理，建设了全省的综合营帐系统。该系统在经过了较长一段实践的运行后，需要进一步优化系统结构以满足其进一步的业务发展，主要包括：
（1） 如何提高综合营帐系统的运行性能，减少综合营帐运行负荷；
（2） 如何提高系统查询和统计分析性能；如何满足地市个性化业务需求和业务二次开发
（3） 如何提高综合营帐与外部系统之间的数据接口效率
（4） 如何进一步利用综合营帐数据进行数据挖掘、分析业务发展规律、发现业务问题、进行业务二次开发等；
（5） 如何为联通统一经营分析平台提供整合后的数据来源；
为此，江苏联通需要优化其企业信息系统平台。通过该架构，形成江苏联通“第二数据中心”，该数据中心主要承担了以下几类业务：
（1） 提供VIP客户的快速业务管理功能，提供VIP客户的业务发展情况实时监控和VIP客户的优质客户服务；
（2） 提供江苏联通帐务统计报表业务；
（3） 提供江苏联通系统接口平台；
在建设了该架构后，江苏联通的营帐和计费系统的压力得到了合理的分担、提高了系统运行效率，减轻了不断对营帐和计费系统升级带来的投资负担，提高了江苏联通的系统部署灵活性。
解决方案
DSG RealSync为江苏联通的需求提供了最佳的解决方案。
如图所示，系统采用DSGRealSync从计费系统、帐务系统中的指定表的数据复制到一个独立的复制系统上。在独立的复制系统上用于数据查询、统计分析等。
应用效果
DSG RealSync在满足江苏联通业务需求具有明显的特点：
- 1. 降低查询系统存储空间
提供选择性复制功能，所以对于查询系统而言，无需复制生产系统上的所有数据，从而减少查询系统的存储空间。
源系统上的数据库容量总共达到有几个TB，而需要复制到查询系统上的数据只有其中的10多张表，数据量约为几十GB。这是采用磁盘镜像技术所不能达到的。
- 2. 满足性能指标
在能够提供逻辑复制功能的工具中，RealSync针对电信级大业务量数据所设计的，因此在性能上完全满足业务系统的需求。
- 3. 可提供优化的查询系统
源数据库系统和目的数据库系统的可异构，主要包括索引规则和存储参数（如数据块大小、回滚段等）。因此可以在查询数据库上根据业务特点进行调整和优化，完全不受源系统的限制。
2.10 辽宁网通数据复制应用案例
客户背景
辽宁省通信公司是秉承辽宁通信业一百多年发展历史的大型通信企业，是辽宁地区实力雄厚、品牌强劲的基础电信运营商。主要经营国际、国内各类固定电信网络与设施（含本地无线环路），经营基于电信网络的话音、数据、图像及多媒体通信与信息服务业务，以及与通信及信息业务相关的系统集成、技术开发、技术服务、信息咨询、广告、通信设备销售、设计施工等业务。
项目需求
辽宁省通信公司为了适应业务发展及日益激烈的市场竞争的需要，决定开发新一代电信运营支撑系统。整个系统建设分别围绕利润，服务，管理三个主题分阶段分步骤的开展。
在项目实施的第一个阶段建设综合服务提供平台，联机采集系统，综合业务计费帐务系统，综合结算系统，资源管理系统，交换网网管系统等系统，在以客户为中心的总体企业经营理念的指导下，为解决快速、有效和可控的服务提供与保障方面的问题，综合服务提供平台成为第一阶段建设的系统当中的重点。
其中统计分析业务在辽宁网通的重要性显得非常突出，因为在当实现了省业务支撑系统的集中建设后，大量的统计分析应用对系统提出了很高的要求。因此辽宁网通在省业务支撑中心决定建设一个集中的统计分析平台，该平台独立于各生产系统服务器，建设专用的统计分析系统，该系统拥有独立的数据、服务器、大容量存储和统计应用程序。并且统计分析系统逐渐可发展为经营决策分析系统，
系统环境
如上图所示，需要DSG RealSync进行复制的业务系统包括6大类组成：
ü 计费系统：有两台IBM服务器组成HA架构，运行ORACLE 9I数据库；
ü 营收系统：有两台服务器组成HA架构作为oracle数据库服务器，另外两台作为应用服务器（应用服务器不在复制范围之内）
ü 综和服务平台：有两台IBM服务器组成，运行ORACLE 9I数据库；
ü 资源管理系统：有两台IBM服务器组成，运行ORACLE 9I数据；
ü 网间结算系统：有两台IBM服务器组成，运行ORACLE 9I数据；
ü 网管系统：有两台IBM服务器组成，运行ORACLE 9I数据；
各系统的容量大小为：
|
业务模块 |
有效容量（TB） |
|
营收＋计费系统 |
13.00 |
|
网间结算系统 |
12.10 |
|
综合服务平台 |
4.80 |
|
交换网网管 |
3.60 |
|
资源管理 |
0.80 |
解决方案
统计分析系统的独立，从根本上解决了统计分析与生产系统的资源争用问题，大量的统计分析应用并不会影响到生产系统的处理性能。这样一方面可以提高统计分析的处理性能，提高统计分析的运行效率，也提高了生产系统的运行效率和健康程度。
由于当生产系统与统计分析系统相互独立，关键问题就在于如何实现统计分析系统上的数据更新，如何保证统计系统数据实时反映生产系统的业务变化。
DSG推出的实时数据库复制技术RealSync为这个问题提供了很好的解决方案，该技术对选定的数据对象进行复制，将这些选定对象的变化复制到另外一个数据库实例作为报表、查询以及使用，系统异构，对生产系统的低干扰性，适合高速、准确要求。
DSG RealSync为辽宁网通解决了此问题，通过RealSync产品从生产系统上将需要提供统计分析功能的数据实时提取到统计分析平台上来，保存到统计分析的专用磁盘阵列，用于统计分析工作。统计分析系统要求数据库在线，且分析数据要保存2年以上的应用数据。
这样通过RealSync将生产系统上产生的数据实时复制到统计分析系统上，保证了统计分析数据的及时更新。解决了独立的6大业务系统的数据集中整合问题，建设了集中的统计分析系统，并为发展成为统一数据仓库系统奠定了基础。
DSG RealSync在满足该系统需求上，存在以下几个特点：
ü 灵活的复制结构：
支持N:1的复制，实现辽宁网通6大分散业务系统的数据集中和整合。
ü 按需复制：
RealSync系统支持对指定信息的按需复制，在方案中只需要复制指定系统中的关键业务数据，而对那些中间结果和临时数据则无需复制，减少统计平台需要的存储容量。
ü 系统异构，可提供更多的优化空间：
目标系统与源系统可采用不同的服务器和磁盘阵列，并且源数据库系统和目的数据库系统的可异构，主要包括索引规则等。
2.11 上海松江财政容灾系统应用案例
业务需求
随着计算机应用系统的爆炸式发展，业务量迅速增加，业务种类日益复杂，系统必须管理不断增长的信息流量；随着信息量的急剧增大，核心数据的管理变得日益困难。如何安全、可靠地存储业务数据及满足未来业务数据高速增长的需要；如何有效管理日益增长的业务数据；如何实现业务数据的共享并在现有业务数据之上建立新兴的增值应用，如数据仓库、客户关系管理（CRM）等，成为了各企业建立信息系统的关键所在。
因次上海松江财政局计划建设一个集中的数据中心，将其所下属的相关单位的财政数据集中收集到数据中心。通过收集过来的数据实现两类目的：
（1） 作为各单位重要数据的灾备中心；
通过实时复制的方式将各下属单位的重要财政数据上收到数据中心，当各系统能够因为灾难造成业务停止或数据丢失时，能够在灾备中心进行业务接管和数据恢复。
（2） 建立数据仓库平台；
通过实时复制的方式将各下属单位的重要财政数据上收到数据中心，再从集中数据库中通过ETL工具抽取关心的业务数据进入数据仓库中，进行财政数据的分析、汇总和数据挖掘。
方案设计
1、一期建设范围
一期将其下属的三个重要的数据库进行上收。
ü 上收的数据包含3个oracle数据库;
ü 共计约400个user下的数据；
ü 数据量总共为几十GB。
2、系统结构
根据财政核心业务系统的需求及其业务特点，我们建议的系统结构图如下所示：
解决方案特点
1、主备系统数据库处于双活状态
上海财政系统数据同业务要求在复制链路中的各个数据库都处在活动状态，其中容灾数据库承担了数据容灾备份，在任何一个生产数据库发生灾难时需要及时提供业务的接管和及时的数据恢复，同时，灾备数据库一直处于open状态，可以对灾备数据库进行实时访问，系统保持生产中心和灾备中心的数据库处于双激活状态；
推荐解决方案采用了DSG RealSync实现生产数据库源系统到容灾系统的复制工作。可以从技术上保障目标数据库在线可用，容灾数据库的数据实时可读取，复制过程和数据读取不产生矛盾。RealSync的复制延迟很小，从容灾数据库读取到的数据是实时最新数据，不需要为了读取到最新数据而进行一些切换工作。
2、N:1的容灾架构，适合于集中容灾的方式
DSG的容灾解决方案可实现异构系统下的N:1容灾体系结构，可实现一套容灾系统对多套生产系统提供容灾服务，减少为每套生产系统建设一套容灾系统模式下的高投入。
3、异构环境的容灾方式
RealSync的容灾解决方案为用户提供的是基于逻辑的数据复制解决方案，因此对于本地系统和容灾系统来说，其硬件平台可以属于不同的厂商、不同的型号，可采用不同的操作系统等。基于逻辑的数据复制屏蔽了底层物理数据的差异。
正如此案例，需要上收的系统分别采用了不同的硬件设备，包括HP-UX,AIX,Linux等有使用。这些系统所采用的硬件平台各不相同。系统采用RealSync提供的异构容灾解决方案时可以选择不同的异构存储平台作为容灾系统的存储平台。
2.12 山东联通计费系统容灾及查询平台应用
1、项目需求
本工程需要对GSM计费系统上的数据提供数据复制支持，提供容灾和计费数据查询功能。计费系统在线系统保存5+1的数据，容灾系统上只要求保存2月（上月＋当前月）的数据用于容灾和查询。
为了满足该要求，如果采用常用的磁盘镜像技术的话，那么将有几个问题是无法有效解决的，或者说如果解决该问题的成本是非常昂贵的：
n 不能实现按需复制：
磁盘镜像无法实现按需容灾技术，即在计费系统中只需要提供1+1月数据的容灾保护，而在生产系统上有5+1月数据。磁盘镜像技术只能对5+1数据提供容灾复制，这样必将提高存储容量3倍以上。
n 容灾数据无法实现有效的数据查询功能：
与其他任何保险策略一样，对容灾系统而言，没有灾难出现时，我们根本无法意识到容灾系统所起到的作用，无法回收容灾系统建设所需的大量投资。当未出现灾难时，我们的容灾端系统总是处于空闲状态，花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。
一些磁盘复制技术厂商推出了BCV等技术以解决该数据复用问题，而该方案需要用户购买1倍的磁盘空间，并且数据还不能实时访问。
因此，如果采用传统硬盘复制技术解决以上问题的话，但就硬盘容量投资上讲就将浪费6倍的硬盘。
2、DSG解决方案
DSG公司推出的RealSync容灾解决方案为该需求提供了最佳的解决方案。
该技术与磁盘镜像技术的根本区别在于，RealSync是在逻辑级，通过传输和运行数据库事务（Transaction），来实现生产系统的数据实时复制到容灾系统上的。
这样该软件可提供该项目需求中的两个重点支持：
（1）按需选择复制：
由于该软件是在逻辑级别复制，所以生产系统和容灾系统在数据管理方面可以采用不同的策略，如在生产系统上保存5＋1月数据，而在容灾系统系统上只保存1+1数据。
RealSync可指定只对当前月和前一月的1＋1数据进行复制。
（2）容灾数据库可提供数据实时访问，而不需要额外的存储投资
采用RealSync复制技术，容灾站数据库系统始终处于打开状态，不同于磁盘镜像技术中的容灾数据库系统在进行数据复制是不可用的。因此，在RealSync热容灾解决方案中，可以通过容灾系统为其它系统提供数据共享服务。如通过容灾系统为计费系统查询功能。
同时该功能还无需像BCV那样购买多一倍的存储空间。
采用DSG RealSync实现山东联通计费系统容灾方案结构如下：
如上图所示：本次工程是采用DSGRealSync将GSM计费系统上的2个RP8400和2个HP N4000上的4个数据库复制到1个容灾系统上。
n 使用RealSync完成计费系统数据表复制功能；
n 实现选择性复制，只复制那些需要容灾的数据，在本方案中就是1+1月的数据；
n 实现容灾系统上的数据只保存1+1月数据的方案，在每月末，通过脚本定时执行的方式或人工操作的方式将前3个月的数据删除；
n 实现容灾系统的数据查询功能，当数据复制过程中，容灾端数据也可以提供外部查询功能。
2.13 SnapAssure在xinjiang移动BOSS系统备份的应用
中国移动BOSS备份系统所面临的挑战
以xinjiang移动为例：
截止到2006年年底，xinjiang移动已经拥有超过200万的用户，xinjiang移动BOSS系统的主机以HP，IBM公司的产品为主，有少量的SUN公司的服务器。
xinjiang移动目前主要的业务支撑系统包括：CRM系统、帐务系统、计费系统、综合结算系统、统计分析系统和客服系统等等。数据库系统全部使用Oracle，为了节省主机资源，Oracle数据库全部运行在非归档（No Archive Log）模式下。
xinjiang移动原有的备份系统是以磁带库备份为主，其中存在严重的问题和挑战：
1） BOSS系统的数据备份没有完整的备份策略
由于xinjiang移动BOSS系统中使用的Oracle数据库非归档模式，维护人员无法实现在线数据的热备份。目前，只能以将重要的数据库表倒出成文件再备份到磁带库的方式进行备份，这种方式需要进行大量的手工操作和人工干预。因此，在线数据以及本地备份数据的备份工作效率很可能不高，备份下来的文件也无法进行版本的管理和控制，xinjiang移动还不能做到自动备份和高效管理。
2） BOSS系统的数据备份没有进行异地保存
BOSS系统的数据进行的备份都是本地的备份。即从生产主机上把重要数据备份到本地的磁带库进行存储，所有操作都在中心机房内执行。
由于xinjiang移动目前还没有建设远程的容灾系统，备份数据也没有做到异地的保存。那么一旦发生灾难性的事故，磁带的读写性能低，在恢复测试、介质访问管理方面都存在问题；更重要的是，非归档模式下的Oracle无法进行在线的热备份，这种状况对xinjiang移动业务数据的安全构成了很大的威胁。可见，xinjiang移动缺少一套备份数据的异地保护方案。
3） BOSS系统的数据备份无法定期执行恢复性的测试
BOSS系统的数据备份无法定期执行恢复性的测试主要有以下三个原因：
l 没有足够的资源进行恢复测试，这个资源指的是足够的恢复测试空间和恢复测试用的主机。测试主机的操作系统需要与业务系统主机的操作系统保持一致、安装的数据库版本需要相同、同时物理卷和逻辑卷的结构也需要尽量保持的一致。
l 数据恢复测试时间过长，缺乏人员进行跟踪检验，对于数据量非常大的CRM、计费、经营分析等系统，进行一次恢复的测试需要很长的时间。大约需要十几个小时才能够恢复完成，一是由于现有的磁带速度太慢，即使目前最快的磁带机LTO2可以达到的实际环境备份速度也仅在13-15MB/s左右，备份恢复的性能明显过低。二是因为数据的恢复由多个恢复步骤组成，除了全恢复以外还要做若干个增量的恢复，恢复步骤烦琐也是恢复时间过长的重要原因之一。另外，对于一些数据库表的恢复也必须通过全恢复后才能对数据表进行提取，所以部分数据的恢复测试工作要耗时更长。这也是无法进行恢复测试的一个重要原因。
DSG SnapAssure建设方案：
DSG SnapAssure为xinjiang移动提供了整体的、有效的备份升级解决方案，BOSS系统中的重要模块都实现了在线、集中、热备份的方式，如图：
方案特点如下：
- 1. 支持Oracle数据库非归档状态下的备份
对xinjiang移动的所有重要数据库，在其Oracle的非归档模式下，实现了全球首创的在线自动热备份，并实现了集中统一备份管理和集中统一恢复管理。
- 2. 完整的备份策略
BOSS系统数据是非常关键的，同时考虑到业务的连续性，这些数据都需要在不停机的情况下进行在线数据备份。
备份策略设定如下：
l 以一周为备份周期，每周日进行一次数据库数据全量备份，其余每天进行数据增量备份；
l 业务数据库增量数据备份启动时间设定在每天的夜间进行，避开业务繁忙的时段；
l 备份数据在磁盘上保留两周的版本，即两个全备和12个增量备份。
- 3. 快速的恢复
系统支持1TB数据库的完全恢复时间在2-4小时左右。
- 4. 支持单表直接恢复
当生产系统因人为误操作而造成表数据丢失时，可从DSG SnapAssure备份系统上直接恢复指定表的记录。
- 5. 实现备份数据的可靠性验证，应对赛班斯法案的要求
定期进行备份数据的恢复测试验证，赛班斯法案要求每半年进行一次。采用DSGSnapAssure后，可通过DSG的备份验证产品DSG SnapShare，将备份数据直接快速打开，进行有效性验证。这避免了在传统方案中进行校验需要的全恢复，避开了人力物理资源的大量消耗，包括恢复测试的主机消耗、恢复空间的消耗、系统管理员大量工作时间的消耗等等。
3 容灾异构平台的经验
|
券商名称 |
RealSync上线时间 |
生产端主机 |
容灾端主机 |
交易系统名称 版本号 |
|
民族证券 |
2007-2 |
IBM P570 AIX5.3 Oracle10g RAC |
HP DS580 LINUXAS4 ORACLE10g RAC |
恒生集中交易系统3.0版 |
|
中原证券 |
2007-3 |
IBM P570 AIX5.3 Oracle10g RAC |
HP DS580 LINUXAS4 ORACLE10g RAC |
恒生集中交易系统3.0版 |
|
国联证券 |
2006-7 |
IBM P570 AIX5.3 Oracle9i RAC |
HP RX4640 HP 11.23A Oracle9i RAC |
恒生集中交易系统3.0版 |
|
华泰证券 |
2006-3 |
IBM S80 AIX5.2 Oracle9I RAC |
IBM S80 AIX5.2 Oracle9I |
恒生集中交易系统3.0版 |
|
金通证券 |
2006-10 |
HP DS570 Oracle10g RAC |
HP DS570 Oracle10g |
恒生集中交易系统3.0版 |
|
银河证券 |
2006-11 |
IBM M80 AIX5.2 Oracle9I RAC |
IBM M80 AIX5.2 Oracle9I |
金证开放基金系统 |
|
长江证券 |
2007-1 |
IBM P570 AIX5.3 Oracle10g RAC |
IBM P570 AIX5.3 Oracle10g |
恒生集中交易系统2006版 |
4 性能指标占用参考
1、某电信集中计费系统异构平台成功案例：
生产端是两台HP的superdemo oracle9i rac 使用emc的dmx系列阵列
容灾端一台IBM P690用作关键业务容灾接管，以及平时的查询和报表统计
|
项目 |
结果 |
|
生产端表空间容量 |
约2.7T |
|
实际数据量 |
约1.5T |
|
RealSync压缩传输量 |
约350G |
|
首次同步导出时间 |
约5小时 |
|
首次同步过程中源端CPU占用 |
40％－50％ |
|
首次同步过程中源端内存占用 |
400M－600M |
|
首次同步过程中目标端CPU占用 |
12% |
|
首次同步过程中目标端内存占用 |
250M－300M |
|
增量同步过程中源端CPU占用 |
3％－5％ |
|
增量同步过程中源端内存占用 |
500M左右 |
|
增量同步过程中目标端CPU占用 |
5％－7％ |
|
增量同步过程中目标端内存占用 |
300M左右 |
2、某政府行业集中数据管理同台异构平台成功案例：
生产系统2台hp安腾rx8640 oracle9i rac
容灾端两台solaris oracle9i rac用作容灾以及平时供数据仓库抽取数据使用。
|
项目 |
结果 |
|
生产端表空间容量 |
约900G |
|
实际数据量 |
400G |
|
RealSync压缩传输量 |
约100G |
|
首次同步导出时间 |
约3小时 |
|
首次同步过程中源端CPU占用 |
约30％ |
|
首次同步过程中源端内存占用 |
300M－400M |
|
首次同步过程中目标端CPU占用 |
17% |
|
首次同步过程中目标端内存占用 |
250M－300M |
|
增量同步过程中源端CPU占用 |
3％－5％ |
|
增量同步过程中源端内存占用 |
400M左右 |
|
增量同步过程中目标端CPU占用 |
5％－7％ |
|
增量同步过程中目标端内存占用 |
300M左右 |
3、某证券集中交易系统异构平台成功案例
源端两台IBM 570 oracle10g rac
容灾端本地一台以前用作生产系统的HP小型机 oracle10g供客户进行数据的查询，同时检验检验复制数据的准确性。异地容灾端另一台以前用作生产系统的HP小型机oracle10g进行异地容灾。
|
项目 |
结果 |
|
生产端表空间容量 |
约200G |
|
实际数据量 |
约80G |
|
RealSync压缩传输量 |
约55G |
|
首次同步导出时间 |
约40分钟 |
|
首次同步过程中源端CPU占用 |
约15％ |
|
首次同步过程中源端内存占用 |
200M左右 |
|
首次同步过程中目标端CPU占用 |
7% |
|
首次同步过程中目标端内存占用 |
150M左右 |
|
增量同步过程中源端CPU占用 |
3％－5％ |
|
增量同步过程中源端内存占用 |
200M左右 |
|
增量同步过程中目标端CPU占用 |
5％－7％ |
|
增量同步过程中目标端内存占用 |
150M左右 |
