Oracle GoldenGate OGG与Quest Shareplex对比
GoldenGate | Quest SharePlex | DSG RealSync | |
公司背景 | |||
公司介绍 | GoldenGate成立于1995年,一直专注于数据库复制领域,现在已经被Oracle收购,能够得到数据库厂商大力支持,正在开发整合后的新版本,届时功能和性能均能进一步提高。 | Quest Software成立于1987年,公司总部位于美国加州。公司致力与数据库管理软件,SharePlex只是其众多产品中一个非主流的小产品。 | DSG北京公司于2002年8月在北京成立,前身是DSGuardian Inc,注册于美国。主要产品为数据库复制及备份软件。只有几十个人的国内小公司。 |
数据库厂商支持 | Oracle公司产品,能够与数据库一起进行技术支持,并且产品持续与Oracle数据库进行整合中。(☆☆☆☆☆) | 与Oracle有合作关系,但因Oracle不完全公开日志格式,在复制领域无法得到更多技术支持,出现问题后Oracle无法进行支持,版本兼容性容易出现问题。 | 与Oracle无关系。其产品为一位前Oracle人员开发,只有此人能够解决问题,技术力量差,无法对Oracle后继版本有效支持。同样因Oracle不完全公开日志格式,在复制领域无法得到更多技术支持,出现问题后Oracle无法进行支持。 |
产品成熟度 | GoldeGate产品最早发布于1995年,目前版本为10.4,产品成熟度高,在全球有超过2000多个成功案例。 | SharePlex产品最早发布于1999年,目前的版本为7,产品成熟性比较高,在全球有近千个成功案例 | 产品推出时间较短,很不成熟,会出现各种问题,经常需要开发人员在客户现场修改代码,并在客户生产环境中测试运行。仅在国内有少量案例。 |
成功案例 | 在国内有海关总署、体育彩票中心、国家税务总局、北京移动、第一重工等众多大型成功案例。在全球有超过2000多个成功案例。 | 在国内有一些成功案例,包括北京地
税,天津地税,贵州联通,黑龙江移 动,大连商品交易所等客户,在全球有近千个成功案例。 |
客户较少,应用主要集中在数据库升级及备份,实时复制案例较少。 |
产品方面 | |||
兼容性和可扩展性 | 支持Oracle、DB2、SQL Server、Sybase、MySQL、Teradata等各种数据库平台(☆☆☆☆☆) | 仅支持Oracle。 | 仅支持Oracle。 |
复制机制 | 基于交易(Transaction)的复制,可以保证数据复制过程中交易的完整性。
只复制提交交易,保证数据一致性。
使用常规加载方式装载数据,可靠性高。 (☆☆☆☆☆) |
基于SQL的复制,无法保证复制过程中交易数据的一致性。(例如,如果两边数据集不同,则相同sql可能产生不同结果)
复制所有提交和回滚交易,会造成资源浪费,也容易造成两端数据不一致。(其优势是无需保存一定时间归档日志,同时复制无需等待交易提交,对大交易速度较快) |
基于交易(Transaction)的复制,可以保证数据复制过程中交易的完整性。
只复制提交交易。
使用Direct Inser模式插入数据,效率较高但有以下问题: 1 Direct模式复制过程中不检查约束,无法保证目标数据一致性。例如,A表通过外键依赖于B表,如果B表数据出现丢失,A表数据通过Direct Insert会正常插入而不检查约束,导致A、B两表数据不一致; 2 只在高水位线以上插入数据,不充分利用高水位线以下空间,会造成数据库占用空间持续增大,表空间利用率非常低,可维护性差。 3 有客户反映目标记录会出现重复(例如,一个带有主键的表在目标却出现两个相同记录,只是rowid不同)。这是因为direct insert不检查约束的原因。
另外,由于其以来rowid进行映射,如果数据库维护过程中出现行迁移操作,会使数据复制紊乱,需要重新建立复制关系。例如,以下操作会引起行迁移: alter table move tablespace alter table split partition alter table merge partition alter table move shrink tablespace |
数据类型支持 | 支持XML Types,Nested tables,Clustered tables,IOT from/to Non-IOT | 不支持XML Types,Nested tables,Clustered tables,IOT from/to Non-IOT | |
是否可只读取归档 | GoldenGate支持只读取归档日志模式,也可以在其它主机上读取从主机共享过来的归档日志,可以在实时性要求不高的情况下最小化对生产系统的影响。
(☆☆☆☆☆) |
目前尚无消息证明其能够支持只读归档日志 | 目前尚无消息证明其能够支持只读归档日志 |
数据过滤和变换 | GoldenGate提供丰富的内建函数,只需简单配置即可实现灵活的数据过滤和转化,无需消耗数据库本身资源。
(☆☆☆) |
Quest SharePlex需要依赖Trigger、SP等数据库内部对象实现过滤和转换,系统消耗高,实现复杂。 | (需验证)机制应当与Quest类似 |
源系统插入性 | 无需在源端插入任何表、触发器、存储过程等数据库对象,对生产库影响非常小。
(只针对DML复制) (☆☆☆) |
需要在源端建立部分中间表,对源库产生一定影响。 | 需要在原系统上插入大量的数据表,这些数据表占用大量的存储空间,维护起来相当麻烦;如果一旦这些中间表丢失数据,需要花费大量的时间重建复制,是可靠性不高的一种设计。 |
系统资源占用 | 正常复制时与数据库交互极少(只有在读取数据字典和日志中没有完整数据如大对象时才会访问源库),复制效率高,对源系统的影响非常小,所有复制进程CPU占用率在5%以内(☆☆☆) | 需要与数据库交互,复制效率相对低,所有复制进程CPU占用率在10%以内。据称其最新版本资源占用与OGG基本相当。
|
复制进程CPU占用率在10%以内 |
数据复制能力 | 1,000G-1,8000G日志量/天
提供若干小交易合并为一个大交易和大交易拆分为小交易的选项,对于OLTP应用性能非常高。(☆☆☆☆) |
Quest最新版本7性能得到了很大提高,基本和GoldenGate类似,具体数据不明。
其以前的版本只能复制300G-400G日志量/天。 由于复制回滚交易,无法提供交易合并和拆分的功能。 |
因为其使用了Direct Insert模式,DSG的性能比较高。
这种模式可靠性低,只是用来作为批量加载,Oracle不推荐作为实时复制。 |
双向复制 | Goldengate可以非常好的支持同一个业务系统同一套表的实时双向复制。 | Quest支持双向复制。 | DSG基于rowid实现源和目标的数据库复制,从机理上肯定不能实现双向复制,同时当源端进行数据库整理时,数据的rowid会发生变化,会造成数据不一致。 |
反向回切 | 当源出现问题时,前端应用可以无缝切换到目标系统,此时目标系统会将此期间所有变化记录下来,待源系统修复后,可以自动将源出现问题期间的变化数据同步回去,最大程度的较少回切时间。 | 基本同GoldenGate。 | 基于rowid实现源和目标的数据库复制,当源出现问题,前端应用切换到目标系统,当源修复后,只能将目标系统全库同步回源系统,然后再切回去,当数据量比较大时,需要的时间会非常长。 |
网络带宽占用 | 因为有数据压缩功能,网络上传输的数据仅为数据库日志量的三十分之一,网络带宽占用最小。(☆☆☆☆) | 网络带宽相对较大,数据的传输量是数据库日志量的三分之一到四分之一。 | 网络带宽相对较大,数据的传输量是数据库日志量的三分之一到四分之一。 |
不同oracle版本支持 | 支持oracle8i以后所有版本,以及RAC环境,在各种版本上均有大量成功案例。 | 支持oracle8i以后所有版本,以及RAC环境,在各种版本上均有大量成功案例。 | 支持Oracle8i以后所有版本,但由于其技术力量有限,通常需要很长时间才能支持Oracle最新版本,并且会有较多技术问题难以及时解决。 |
容错能力 | 软件使用检查点机制记录当前完成复制的位置。在日常运行过程中,如果由于网络中断、数据库实例失败、存储空间不够等原因造成复制停止,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实现源和目标的同步,因此必须使用其自己的初始化工具进行初始化,速度比较快,但初始化过程中要求生产端不能有数据变化或者编译存储过程等维护操作,否则会造成数据不一致。 |
Appendix OGG VS SP – OS/DB/Data Type/Objects support matrix
Items | GG | SP | |
DB | Oracle | √ | √ |
DB2 | √ | X | |
MS SQL Server | √ | X | |
Sybase | √ | X | |
Teradata | √ | X | |
My SQL | √ | X | |
HP SQL/MX | √ | X | |
Enscribe | √ | X | |
OS | IBM-AIX | √ | √ |
Sun Solaris | √ | √ | |
HP-UX | √ | √ | |
Linux | √ | √ | |
Windows | √ | √ | |
IBM zOS | √ | X | |
HP Nonstop | √ | X | |
HP True64 | √ | X | |
Data Types | NCLOB | √ | X |
INTERVAL | √ | X | |
XML Types | √ | X | |
Objects Support | Nested tables | √ | X |
Clustered tables | √ | X | |
MV to MV | √ | X | |
IOT from/to Non-IOT | √ | X | |
DDL | ANALYZE TABLE | √(New 11g) | X |
ANALYZE INDEX | √(New 11g) | X |
Leave a Reply