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