RealSync-Oracle异构热容灾解决方案

[复制链接]
查看11 | 回复9 | 2009-2-23 21:48:25 | 显示全部楼层 |阅读模式
RealSync-Oracle异构热容灾解决方案
前言
世贸大厦的倒塌使得800多家公司和机构的重要数据丢失,无数的企业成为这一恐怖事件的殉葬品。然而正当大家为此扼腕痛惜时,金融界巨头Morgan Stanley 公司竟然奇迹般地宣布全球营业部第二天可以照常工作,因为先前建立的远程容灾系统保护了重要的数据,从此人们更加清楚地看到容灾的重要。
但目前主流的容灾技术(磁盘阵列复制方案和存储卷的解决方案)却让很多的企业不敢奢望,因为现有的容灾解决方案要求至少数千万的投资(昂贵的磁盘存储系统和昂贵的存储卷管理系统)。并且在灾难未发生时容灾端的投资闲置,加上大量实验证明的灾难发生时容灾系统不可靠等因素,都使得许多客户在容灾建设上不得不望而却步。
RealSync-数据库逻辑复制技术提供异构热容灾解决方案
DSG RealSync容灾解决方案通过对数据库系统的数据复制及灾难切换支持,为企业提供关键业务支撑系统更可靠、投资更低、结构更灵活、回报率更高的容灾解决方案。
该技术与远程磁盘镜像技术的根本区别在于:RealSync是在逻辑级,通过传输和运行数据库事务(Transaction)来保持生产和备份数据库数据的一致性。
一旦数据库因某种情况而不可用时,备份数据库将正常切换或故障切换为新的生产数据库,以达到无数据损失或最小化数据损失的目的,为业务系统提供持续的数据服务能力, 同时,利用备份数据库的数据提供查询、统计分析、数据抽取等增值服务。
RealSync-满足工作组、企业到数据中心的容灾需求
RealSync在工作组和企业级的关键应用的容灾支持上,能够提供比竞争对手更低成本、更高投资回报、结构更灵活、更容易实施和维护的容灾解决方案,提供对主流的Windows、Linux和Unix等跨平台的Oracle数据库系统的复制和容灾切换支持。
在大型企业和数据中心级的关键应用上,RealSync是完全满足数据中心级每秒数千条交易量的实时复制支持、秒级的数据库切换和99.9%以上的切换的可靠性容灾解决方案,并且通过处于打开(open)状态的备份数据库提供数据仓库、查询、统计报表和实验系统等支持企业应用模块的重新部署。
RealSync-相对于存储容灾技术的优势
?
广泛的异构环境支持
RealSync技术是逻辑级的数据复制技术,因此对于生产系统和容灾系统来说,其硬件平台可以属于不同的厂商、不同的型号,可采用不同的操作系统等。它的优点在于:一方面为用户提供容灾系统建设时,硬件平台的可灵活选择空间;同时提供了在同一容灾解决方案架构下,实现企业不同平台上的多个信息系统的统一容灾支持。
?
容灾数据库处于OPEN状态,提供及时、可靠的容灾切换
RealSync维护的容灾数据库在数据复制过程中始终处于打开状态,为保证灾难切换的时效性和可靠性:
?
打开的备份数据库保证数据复制在逻辑上的完整性,为源系统提供了永远可用的后备数据库系统,确保容灾系统的可靠性。
?
当源系统出现故障时,应用系统可实现实时访问备用数据库系统,无需重新启动备用数据库,达到数据库的秒级切换目的。
?
容灾数据库可提供实时数据共享,支持企业应用负载分担和投资回收
采用RealSync容灾技术,容灾数据库始终处于打开状态,不同于其他模式下容灾数据库系统不可用的状态。因此,可以通过RealSync维护的容灾系统,提供数据共享服务:
?
为决策分析和报表系统提供快速的数据抽取功能
?
提供准实时脱机查询,提高查询效率
?
为试验系统提供真实的生产数据
将以上本来需要在主系统上运行的业务与生产系统完全隔离,充分利用容灾系统的资源,实现企业应用负载分担,减少对生产系统的影响,提高服务系统响应效率;从而将容灾系统这个成本中心转化为利润中心。
?
灵活的组网结构和低带宽资源需求
RealSync采用交易(Transaction)传输方式,极大的减少了复制过程中需要传输的数据量。使得在网络上传输的数据量大大减少,要求更低的网络带宽。
Realsync支持标准的TCP/IP网络传输,用户可灵活布建容灾网络架构。
系统可支持1:1、N:1、1:N和双向容灾结构支持,提高企业容灾结构的灵活性。
RealSync-相对同类数据库容灾技术的特色
?
采用独特技术,保证提供数据中心级数据复制性能要求
RealSync采用了智能行映射IRM(Intelligent ROWID Mapping)技术和独创DXF(DSG extend Fomart)交易格式,将交易级复制技术性能和资源需求标准提升到满足数据中心级的数千条交易/s的复制性能需求,改变了其他同类技术不能应用于数据中心级的现状。
IRM技术使得在容灾数据库上的数据库指令的执行,避免了大量的记录查找和定位操作,尤其是针对update和delete等IRM技术让容灾数据库的操作能够直接定位到目标位置,减少执行标准SQL where子句时占用的复杂定位操作。从而能够满足数千条update操作/s的复制性能。
DXF格式是一种最高效率表达交易指令的数据格式,表达形式丰富,满足不同指令类型、不同数据类型的表达要求,并且能够直接转换为ORACLE的内部表达格式,从而将容灾数据库上执行相同指令所需的时间和资源仅为主系统资源的1/5以下。
?
提供存量数据的初始装载和容灾系统重新初始化支持
RealSync还提供了容灾系统数据初始装载功能支持,将主系统上的已有存量数据,在不中断业务的情况下平滑的装载到容灾数据库上。而同样的工作在其他同类解决方案中,需借助第三方解决方案来实现。
RealSync数据表
特性
描述
工作方式
Transaction-Based数据复制
目标系统支持的操作
目标系统支持Read-Write操作
支持的数据库版本
Oracle 8,8i,9i
支持的异构硬件平台
Sun, HP, IBM, x86
支持的异构操作系统
Solaris, AIX, HP-UX, Linux
支持的存储系统
EMC,IBM,HDS、HP、SUN以及其它通用的SCSI/FC存储系统
故障接管时间
数据库接管时间秒及
故障恢复
支持故障切换和故障回切(Switch Back)
支持的容灾结构
一对一,双向,一对多,多对一
复制时间间隔
可灵活设置
带宽占用
为传统存储复制技术的1/7以内
最大距离
没有限制
对系统性能的影响
对主系统CPU占用率<5%。
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
对这个没研究,个人感觉就和shareplex差不多的原理了,理论上很完美,兼容性上可能有些方面不支持,操作起来,可能还需要一些手工的干预
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
很多人研究了oracle redo/archive log的格式,都在做这种东西。。。
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
DSG 的产品跟 quest 的产品拼的火热,在pub上两个厂商的工程师也一度就技术和市场争的火热
从技术的角度无非都是抽取redo log 信息之后通过自己的格式传递到远程接收端再应用到数据库。只是产品描述包装起来整的外行觉得很神秘。
老顾现在没再关心oracle 不知道罢了
DSG 和 quest 都有自己的缺陷,当然特指某些情况,方案么正常运行都没事,可对于异常和环境的变化,管理的复杂度其实也蛮高的,除非应用、数据结构、环境不再发生变化。
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
嗯,这二个产品基于抽取SQL的,正常时倒应还可以,但一些特殊情况下,应是问题很多的
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
有行内人士?了解bug的?如果由于商业角度,不要说是那个产品。
我向大家都有兴趣听一听什么时候会出问题。这些东西还是有一定的市场的。我只知道当系统变化的时候,几乎相当于重新配置了一遍,管理成本高一些。
我以前建议客户的时候都是两套方案同时用,平时用这些花哨东西满足客户不切实际的需求,另外自己准备一个后备方案,设定base line,防止客户那边出问题反被拉出来批斗。不过投资也蛮高的,幸好一般这一类用户都很有钱。
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
就我感觉,(不一定对,哪位了解的可以说说),这种产品一般会在如下几个情况下出现问题
1 不支持一些数据类型
2 生产数据库DDL操作,修改一些结构时
3 不同版本数据库的SQL语法不匹配
4 工作负荷很大时,来不及抽取SQL
5 网络短暂中断
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
最初由 prada_gu 发布
[B]就我感觉,(不一定对,哪位了解的可以说说),这种产品一般会在如下几个情况下出现问题
1 不支持一些数据类型
2 生产数据库DDL操作,修改一些结构时
3 不同版本数据库的SQL语法不匹配
4 工作负荷很大时,来不及抽取SQL
5 网络短暂中断 [/B]

1:可能对于 自定义类型、过大的lob 字段等有限制
3:对于日志的抽取dml的问题,一般不存在 sql语法的问题,dml都是简单的根据pk或者无pk下根据列去完全匹配的。
4:一般可以从归档日志抽取,这个没关系,最多延迟,是需要经过压力测试的,quest测试过一天产生400G的归档(主机信息不详)
5: 网络中断没关系,恢复后会继续在断点进行的。

大体上两者有如下差异,不知道是否记错:
DSG 和 quest 有一个差异就是,dsg 是当事务提交后才将事务对应的变化应用到目标数据库的,quest 是直接根据日志应用,事务回滚时候再做对应的回滚操作。
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
为什么不用dataguard呢?这个有什么问题嘛?
回复

使用道具 举报

千问 | 2009-2-23 21:48:25 | 显示全部楼层
要是表没有pk,那会如何处理?使用rowid?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行