| GoldenGate | Quest SharePlex | DSG RealSync |
公司背景 | |||
公司介绍 | GoldenGate成立于1995年,一直专注于数据库复制领域,其主力产品GoldenGate TDM软件是业界著名的数据库复制平台。 | Quest Software成立于1987年,公司总部位于美国加州。公司致力与数据库管理软件,SharePlex只是其众多产品中一个非主流的小产品。 | DSG北京公司于2002年8月在北京成立,前身是DSGuardian Inc,注册于美国,另有说法DSG为美国DSGuardian公司在国内办事处和研发中心。主要产品为数据库复制及备份软件。 |
产品成熟度 | GoldeGate产品最早发布于1995年,目前版本为9.5,产品成熟度高,在全球有超过2000多个成功案例。 | SharePlex产品最早发布于1999年,目前的版本为5.3,产品成熟性比较高,在全球有接近800个成功案例 | 产品推出时间较短,很不成熟,会出现各种问题,经常需要开发人员在客户现场修改代码,并在客户生产环境中测试运行。仅在国内有少量案例。 |
成功案例 | 在国内有海关总署、体育彩票中心、中国电子口岸、海南移动等众多大型成功案例。在全球有超过2000多个成功案例。 | 在国内有一些成功案例,包括北京地 税,天津地税,贵州联通,黑龙江移 动,大连商品交易所等客户,在全球有近800个成功案例。 | 成功案例较少,主要集中在数据量较 小的客户群。 |
产品方面 | |||
复制机制 | 基于交易(Transaction)的复制,可以保证数据复制过程中交易的完整性。 | 基于SQL的复制,无法保证复制过程中交易的完整性,灾难发生时有可能会出现交易中只有部分数据被复制到目标端从而造成数据紊乱。 | 基于交易(Transaction)的复制,可以保证数据复制过程中交易的完整性。 |
系统资源占用 | 无需与数据库交互,复制效率高,对源系统的影响非常小,所有复制进程CPU占用率在5%以内 | 需要与数据库交互,复制效率相对低,对源系统的影响比较小,所有复制进程CPU占用率在10%以内 | 需要在系统中创建大量的表,占用大量的存储资源。复制进程CPU占用率在10%以内,源系统中的表难于监控,可能对生产系统造成 不可预知的影响。 |
数据复制能力 | 1,000G-1,8000G日志量/天 | 300G-400G日志量/天 | 300G-400G日志量/天 |
双向复制 | Goldengate可以非常好的支持同一个业务系统同一套表的实时双向复制。 | Quest不支持同一套表的实时双向复制。 | DSG基于rowid实现源和目标的数据库复制,从机理上肯定不能实现双向复制,同时当源端进行数据库整理时,数据的rowid会发生变化,会造成数据不一致。 |
反向回切 | 当源出现问题时,前端应用可以无缝切换到目标系统,此时目标系统会将此期间所有变化记录下来,待源系统修复后,可以自动将源出现问题期间的变化数据同步回去,最大程度的较少回切时间。 |
| 基于rowid实现源和目标的数据库复制,当源出现问题,前端应用切换到目标系统,当源修复后,只能将目标系统全库同步回源系统,然后再切回去,当数据量比较大时,需要的时间会非常长。 |
网络带宽占用 | 因为有数据压缩功能,网络上传输的数据仅为数据库日志量的三十分之一,网络带宽占用最小。 | 网络带宽相对较大,数据的传输量是数据库日志量的三分之一到四分之一。 | 网络带宽相对较大,数据的传输量是数据库日志量的三分之一到四分之一。 |
兼容性和可扩展性 | 支持Oracle、DB2、SQL Server、Sybase、MySQL、Teradata等各种数据库平台 | 仅支持Oracle。 | 仅支持Oracle。 |
不同oracle版本支持 | 支持oracle8i以后所有版本,以及RAC环境,在各种版本上均有大量成功案例。 | 支持oracle8i以后所有版本,以及RAC环境,在各种版本上均有大量成功案例。 | 支持Oracle8i以后所有版本,但对 Oracle 10G 及RAC环境支持较差。 |
对原系统的改动 | 安装时不需要在原系统上插入表,对原系统的影响非常小,运行可靠性高。 | 需要在原系统上插入一些中间表,影响可靠性。 | 需要在原系统上插入大量的数据表,这些数据表占用大量的存储空间,维护起来相当麻烦,如果一旦丢失,需要花费大量的时间重建,是可靠性不高的一种设计。 |
容错能力 | 软件使用检查点机制记录当前完成复制的位置。在日常运行过程中,如果由于网络中断、数据库实例失败、存储空间不够等原因造成复制停止,GoldenGate能够以自定义间隔自动检测并在异常排除后立即自动恢复复制,保障数据无丢失,使得管理和维护工作中人工介入降低到最小。 | 异常情况排除后,软件需要确认两端数据库中的大量信息,然后才能重新开始复制。这个确认过程最少需要几十分钟的时间,扩大了复制中断的时间。 | 由于产品问题,会频繁出现数据不一致错误,每次出现错误后,都需要大量的手工维护工作,才能继续复制。 |
产品日常维护 | 由于使用了多重检查点机制,一方面能保证在网络中断等一般异常情况排除后,软件能自动快速的恢复正常复制状态,另一方面在遇到因为人为错误等原因造成两端数据不一致的情况下,可以通过调整检查点重新同步的方式方便地恢复数据一致。使维护工作中人工介入降低到最小。 | 在异常排除后仍需要等待很长时间才能恢复正常复制状态。两端数据一旦不一致,需要手工恢复或重新初始化。 | 产品的维护需要大量的人工干预,停止产品时只能通过kill命令直接杀掉进程。 |
产品的运行监控 | GoldenGate提供了集中管理的工具 Director。该工具可以对多个分布的GoldenGate实例进行集中管理,并提供命令行、web页面面和Java 界面三种管理界面,客户可以根据自身爱好选择任意一种方式管理和监控复制软件的运行。Director使得客户可以更加直观的观察复制软件运行的状态,管理和配置复制软件进程和参数,及时处理故障和报警,还可以提供与第三方监控软件的接口。 | 用户可通过shareplex控制台查看数据复制的各种相关信息,并设定个性化的参数以实现特定的功能,管理方便灵活。可与多种监控平台结合,实现数据复制的实施监控(使用SNMP方式)或者与Quest Foglight监控产品集成,实现监控及报警 | 产品运行情况只能通过查看日志了 解,停止产品时只能通过kill命令直 接杀掉进程;监控产品运行情况有较 大难度。 |
初始化 | Goldengate可以和oracle数据库实现无缝结合,充分利用oracle的rman,data pump,exp/imp,在保证数据一致性的情况下,可以高速地实现数据初始化。 | Quest也可以利用oracle的exp/imp初始化工具。 | 由于DSG基于rowid实现源和目标的同步,因此必须使用其自己的初始化工具进行初始化,数据的一致性会出现问题。 |
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17172228/viewspace-776656/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/17172228/viewspace-776656/