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状态是否和源端相同。