DSG RealSync VS. Quest Shareplex

这个也不知道是从哪里转来的,我就记下我看到的url吧。

 

原址如下: http://replication.blog.51cto.com/222909/165446


 

 

DSG RealSync

Quest SharePlex
公司方面的不同点
公司
DSG公司的总部在北京、共有员工50多人,主要产品包括oracle同步软件realsync和数据库备份软件snapassure及其他有关oracle数据库的支撑软件。
DSG公司在北京、上海和广州设有服务机构,在上海有多名技术人员提供技术支持。
Quest Software公司总部位于美国加州,成立于1987年,并于1999年在纳斯达克上市,市值近20亿美元。公司现有员工3000人,中国区总部位于北京,广州、上海设有办事处。
主要产品线为数据库管理和监控工具。
公司规模大于DSG公司。
市场客户
DSG公司的产品主要销售在国内,单就数据库同步软件realsync在国内的客户主要有电信和证券两大行业:
 
中国电信:
福建电信、广西电信、杭州电信、绍兴电信、舟山电信、成都电信、广东电信(迁移)、贵州电信
中国联通:
江苏联通、山东联通、广东联通、江西联通、湖北联通、四川联通、福建联通、湖南联通、内蒙联通
中国联通:
广西移动、甘肃移动(迁移)
证券:
中国金融期货交易所、长江证券、民族证券、中原证券、银河证券、国联证券、华泰证券、金通证券、南京证券、信泰证券、江南证券、    国海证券、西部证券、西南证券、宏源证券、东海证券、华夏基金、远东证券、东兴证券、金元证券
其他:
河北地税、辽宁交通、济南钢铁、江西电力
Quest产品在全球范围内销售,拥有一些国际上的大客户:
 
 
在国内的客户主要有:
 
 
 
 
 
客户反馈情况
售后服务与技术支持
DSG Realsync在国内有50多人的售后服务队伍,分别在北京、上海和广州分布服务人员。
DSG Realsync承诺给用户提供7*24小时的不间断服务。
尤其是在现场服务方面,DSG提供不限次数的现场服务。
 
国内的工程师掌握了产品的核心技术,可提供更专业的产品支持。
Quest在上海、广州、北京有办事处。
可是他们在这些地方能够支持Shareplex的人很少,在上海目前只有1个人能够支持shareplex产品。
从技术力量对产品的掌握程度上说,Quest在国内的工程师对产品的了解深度有限,无法提供深层次的产品技术支持。
 
产品技术方面:
DSG RealSync与QUEST Shareplex都是通过对oracle log信息进行分析,生成交易指令后传输到容灾端进行重新装载的方式来实现容灾的。两个产品在实现原理上属于同类产品。
但是在产品的功能上、性能上,在简化系统的实施、维护和支持国特殊需求方面存在一定的差别。
功能的完善性
数据复制系统的实施过程包括两个阶段:全同步和实时增量同步。
实时增量同步过程是通过对log文件进行分析得到的。
但对实时同步之前必需将存量数据从生产系统导入到容灾系统上。这些数据不能通过log文件分析得到,所以需要另外的实现机制。
DSG Realsync支持了两个阶段的环节。
 
但Shareplex只提供了redo log的实时分析部分,根本就没有第一阶段的任何功能
首次同步的功能
DSG Realsync提供了两个环节的支持:
一是首次初始化;
二是实时增量同步;
 
DSG公司开发了首次全同步功能(full_sync),该功能在整个容灾系统的建设、运行和容灾切换的各个运行环节中,很有用处:
优势一:无需停止业务、无需申请停机时间;
优势二:操作简单:只需要一条命令即可操作,无需过多人为干预;
优势三:多任务并发全同步,提高全同步性能,;
优势四:真正支持不同操作系统、不同存储系统、不同数据库版本之间的全同步;
Quest Shareplex提供了实时同步功能,并不提供全同步功能。
他们的全同步采用其他第三方的方式,主要包括存储拷贝方式(例如backup/restore,或者是mirror等方式)以及逻辑方式(主要是EXP/IMP)。采用这样的方式作全同步将会存在的问题:
n          需要停止业务;
n          导出和导入时间非常长 ;
n          操作过程复杂,需要大量的人为干预。
n          备份恢复方式还需要两端的操作系统完全相同,否则还无法使用该方式
 
Shareplex宣称自己在新版本中提供了不停业务的全同步,那是因为调用了exp/imp的功能。其性能非常慢。
测试方法:我们可以搭建一个300GB的数据库,比较一下和DSG的全同步差别。
比对与修复功能
 
Realsync提供了单表重新全同步的机制进行修复。单表全同步的功能对于操作者来说使用非常简单:
第一:只需要一条命令就可以完成;
第二:不对生产系统产生任何影响,不需要业务中断;
shareplex宣称其比对功能和修复功能非常好,但是我们仔细分析就会存在问题:
 
该软件采用PK方式定位记录进行数据比对,而且采用select方式作为数据的读取接口,其速度非常缓慢。
测试方法:
(1)有PK/UK的表的比对:
在系统中创建2张表,每张表中插入5000万条记录,每条记录的大小为1KB左右,看看比对时间需要多长。
(2)没有PK/UK的表的比对:
在系统中创建2张表,每张表中插入1000万条记录,每条记录的大小为1KB左右,看看比对时间需要多长。
监控界面
DSG Realsync正在提供并且在完善其GUI监控界面,对于进程、日志分析、数据装载、数据传输、队列监控等方面提供了实时监测和错误告警手段
Shareplex提供了SNMP接口方式。
同时也可以和QUEST公司的数据库产品集成实现图形化的界面管理。
但是这样需要购买其数据库管理产品,价格也不低。
对系统的资源占用
在每1.6分钟产生1GB的redo log情况下,DSG Realsync占的cpu资源为 2% (8CPU)
Quest Shareplex占用CPU资源9%。
是否一定要求表具有PK/UK索引
DSG Realsync在装载是采用rowid的方式来定位,而不依赖于PK/UK字段。
这样用户可根据需要在目标端创建不同的index,提高目标系统上的业务针对性
Shareplex必须依赖于PK/UK字段,而对于那些没有PK/UK字段的表,其也能够支持,但是性能却非常缓慢。
这样shareplex也必须要求两端的index最好是相同的,这样才能保证目标端的装载性能。
复制任务的配置是否简单
DSG Realsync在配置需要复制的对象时具有非常灵活的方式,包括:
需要复制的schmea
不需要复制的schmea
需要复制的所有tables
不需要复制的所有tables
Shareplex在配置上,需要为每个table设置映射关系,而且还没有图形界面,试想一下在一个具有几千张上万张表的情况,如何快速的配置这么多的表呢?
是否将新创建的表自动加入到复制队列
在采用schmea配置的模式下,DSG Realsync自动将新create的表加入到复制队列中。无需人为重新配置
 
shareplex只支持按表的复制关系,当新增加表后,新增加的表不自动进入到复制队列,因此必须把业务停下来再将新创建的表加入到复制队列中去。
这个问题导致XX客户每月出帐后都需要停机一晚上,再将整个系统作一次重新拷贝。
支持对重要DDL的备份功能
DSG Realsync不仅支持将DROP TABLE,TRUNCATE TABLE等破坏性操作的过滤,更为重要的是提供了这些操作在目标端的备份功能:
例如当目标端在装载drop table命令时,realsync会首先对删除的表作一个rename操作,将其备份成一个别的表后再删除该表,从而给用户一个恢复的机会。
SharePlex支持对drop table,truncate table的ddl的过滤操作,但实际上单纯的过滤无法满足业务需求,因为很多时候的表就是要作这些操作的,如果一旦过滤将会影响到正常的使用。
日志分析的性能
从大量的应用情况来看DSG RealSync在处理性能上优于同类方案。
在福建电信项目中采取了积压日志分析的方式进行测试,预先产生4GB的日志数据,然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名,在800秒内产生的4GB日志,realsync只需要100秒分钟即能分析完累积的日志,其速度远远高于产生日志的速度。
Shareplex的日志分析速度低于Realsync的日志分析速度。
是否支持不同schema之间的同步
DSG Realsync可支持生产系统的schmea名字和目标端的schema名字不相同的情况下的数据复制。
更为重要的是支持两个不同schema名字之间的DDL复制支持,因为Realsync会自动的去替换DDL中的schmea名字
Shareplex只能在两个完全相同的schema名字之间进行DDL的复制。
支持双向复制
DSG Realsync支持生产系统和目标系统之间的角色互换,在一个时间段内生产系统为源端,在另一个时间内目标系统作为源端,实现数据反向复制。
但是DSG Realsync不支持同一时间的同一张表的双向复制
SharePlex支持数据的双向复制.
SharePlex软件内部还提供了针对双向复制可能产生的数据冲突的处理机制,如以时间戳为标准或以主站点数据为准等。
灾难接管后的回切方式
DSG Realsync建议全部数据的反向恢复
SharePlex建议作变化部分数据的反向恢复
目标端数据的加载方式
DSG Realsync采用rowid的方式作为条件,不依赖于PK/UK,不依赖于索引。
 
Quest SharePlex采用pk/uk作为装载的条件,不依赖于rowid。
支持的数据类型
DSG Realsync不支持UDT,Varray和BFILE数据类型
不支持IOT,CLUSTER TABLE,OBJECT-TYPE TABLE,external table等特殊表
支持UDT ,Varray类型。
但对于BFILE和其他表类型也是不支持。
大事务的处理机制
DSG Realsync是在事务完成后才传输。
对大事务的延迟会加长
Quest SharePlex是按sql命令传,所以大事务的延迟更短。
Trigger的处理
DSG Realsync将trigger以disable状态存在于目标端数据库,且目标端存在一个enable_ddl.sql脚本,该脚本中严格记录源端trigger的状态,切换后只需执行swich脚本即可保证生产和灾备的一致。
例如,生产系统有3个trigger,其中一个是disable状态,那么目标端在切换起来后,其中的一个trigger也是diable状态的。
所有trigger均以disable模式存在于目标端数据库中,一旦发生灾难必须手工enable所有trigger,假设某一trigger在源端就已经是disable模式,这样会造成数据错误,导致灾备系统无法使用。
测试方式:在生产系统创建3个trigger,其中一个为disable状态。测试执行切换操作后,目标端的3个trigger状态是否和源端相同。

 

你可能感兴趣的:(数据库,schema,测试,table,电信,产品)