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