内容发布更新时间 : 2024/5/5 8:29:07星期一 下面是文章的全部内容请认真阅读。

Quest 公司的SharePlex 与 DSG公司RealSync比较

Quest Software公司总部位于美国加州，成立于1987年，并于1999年在纳斯达克上市，市值近20亿美元。公司现有员DSG北京公司于2002年8月在北京成立，是由几个留学生工程师回工3300人，中国区总部位于北京、广州、上海设有办事处。 国的创办的企业，主要产品为数据库复制及备份软件。在公司创建的 短短的几年里，发生了几次拆分，未来前景不明朗。 Quest是业界领先的应用管理解决方案供应商。 Quest在国内有完善的服务体系，经验丰富的技术人员为用户提供实施和培训等全面服务。用户还可以通过Quest专业知识库等技术资源和完备的技术手册来学习和掌握产品技术。 Quest有专门的SharePlex全球技术支持中心，为全球用户提供7*24的技术支持。 SharePlex产品最早发布于1999年，目前的版本为6.0.1，产品成熟度非常高；成熟的产品有效地保障了数据的安全性，避免产品不稳定性对复制环境的影响，10多年来在全球有近1000个大型客户的成功案例。 SharePlex在多个用户环境中运行多年时间，复制链路非常稳定。 由于产品的不成熟及公司规模的限制，不能提供及时及足够的技术支持； 另外公司人员变化较大，无法保证后续的服务。DSG提供的24小时支持，仅是一个工程师手机号码，无法提供专业的技术支持。 公司实力 技术服务 产品成熟度 产品推出时间较短，极不成熟，会出现各种问题，经常需要开发人员在客户现场修改代码，并在客户生产环境中测试运行。 复制链路经常无故中断，且由于监控手段不完善，经常会在中断几天后才发现，需要重新进行全同步。 产品实现原理 Realsync通过从Oracle日志中读取事物信息，传输到目标数据库进行SharePlex通过从Oracle日志读取数据库的所有变化信息，状态，并在目标数据库维护一个rowidmap（记录了源系统和目标系统传输到目标数据库解析成SQL进行装载，整个过程严格遵的rowid 对应关系），在目标数据库通过rowid保障数据的一致性。 守数据一致性的顺序，在目标数据库通过主键技术保障数据 一致性。 这种技术对数据量较少、rowid没有任何变更、没有使用新的数据类型的系统环境可以使用。但无法适用于更广泛的应用环境。 数据一致性的保证 充分保证数据一致性。且在复制DDL操作的配置下，可保证两端数据库结构变化的准确同步。 DSG采用基于rowidmap的方法保证数据的一致性，如果出现rowid记录不准确或发生变化而没有捕捉到的情况，数据一致性就不能充分保证。事实上，这种问题在实际生产环境中经常出现，需要频繁的重新同步数据。 例如：索引和主键等结构无法保证一致，同步后的结构经常会丢失大量主键和索引，DDL操作复制过程中也经常出现错误，导致复制链路中断。再如：如果目标端rowid发生变化(如进行row movement、碎片重组等操作)，就会导致数据不一致。 事务提交后才开始进行复制，在大事务情况下延迟较大，且对大事务在目标端会分成多个小事务提交，无法保障数据的一致性。 事务开始后就进行复制，无论大事务或者小事务都可保证数据复制的实时性，所有事务与源端完全一致 大事务支持 复制过程中对数据的校验 复制过程中可校验数据是否一致，如果发现不一致，可在日由于使用ROWID方式在目标端加载，即使有大量数据不一致，也无志文件中进行记录，并将发生不一致问题具体的SQL语句法发现，用户不能及时了解复制链路的运行情况。数据错误累积下去，记录到专门的文件里，提供详细的诊断信息，以便用户及时会引起相关应用的故障。 解决，避免更多的错误数据。 虽然提供了数据比较功能，但如果比较过程中对数据进行了修改，则SharePlex提供的在线的数据比较功能，如果怀疑发生部分比较结果难以保证，必须重新进行，且保证被比较的表没有数据变化。 数据不一致，可在应用不停机，且被比较的表上有操作的情数据比较仅能定位不一致记录的rowid，需要进行手工的修复，如果修况下动态的比较并定位不一致的数据，并实现在线的自动修复过程中出现新的变化，无法保证数据的一致性，通常只能通过重新复，充分保障数据的一致性。 同步全表完成修复。 数据比较 支持的数据类型 SharePlex目前已经支持几乎所有的Oracle数据类型，对应用程序没有限制。 支持数据类型较少，不支持用户自定义类型（UDT），Varray ，Bfile，Nchar，Nvarchar，XML，IOT，ASM等。 双向向数据复制 完全支持数据的双向复制，在国内外均有运行数年以上的成功案例。 由于产品原理的限制，目标端数据无法进行修改，否则将出现数据不 一致错误，由于目标数据必须由RealSync同步过去，因此无法实现数SharePlex软件内部还提供了针对双向复制可能产生的数据据的双向复制。 冲突的处理机制，如以时间戳为标准或以主站点数据为准等。 SharePlex提供从容灾数据库到生产数据库的反向复制，可将接管后容灾数据库上的变化复制回生产数据库，操作极其无法提供迅速回切功能，需要把生产系统数据库全部清空，在用容灾简单，不需要重新初始化同步,可实现接近零停机时间的计数据库进行重新初始化同步，风险较大。 划内维护。 SharePlex提供成熟的手段进行复制链路的监控和维护 (1) 用户可通过SharePlex控制台查看数据复制的各种相关信息，并设定个性化的参数以实现特定的功能，管理方便灵活。 (2) 可使用自带的图形监控程序，查看相关信息，当发生意外情况时可通过电子邮件实现及时的报警。 (3) 通过丰富的日记记录复制软件的运行情况； (4) 内置支持SNMP和Mail功能，可与多种监控平台结合，实现数据复制的实施监控（使用SNMP方式） 灾难恢复后的数据库回切 产品维护及监控 产品运行情况只能通过查看日志了解，停止产品时只能通过kill命令直接杀掉进程； 监控产品运行情况有较大难度，经常出现复制链路已经中断几天才被发现的情况。 技术细节 产品的成熟度是由细节决定的，SharePlex从用户方面进行考虑，非常关注技术细节。如： (1)DDL可以选择复制或不复制，可以选择在复制出错后的处理方法； (2)提供多种配置参数供用户选择； (3)可以配置延迟复制 (4)可以选择针对指定事务忽略进行复制…… DSG只有一个主程序，其他功能只能靠手工编写shell脚本实现。产品功能显得非常粗糙。没有很多针对用户需求的配置参数。甚至无法了解自身运行队列的大小和处理能力，只能通过操作系统的文件大小进行识别。