据，也无法保证升级后的数据一致性，大量数据出现混乱。为了解决这种情况，需要对升级程序进行分析，对GoldenGate不能支持的操作语句在容灾端手动执行。。。因此，每次应用升级都是一次灾难。 单表修复功能:完美支持 单表修复功能:比较费劲 在平时运行中，由于各种原因导致DSG RealSync只需要一个命令就能对单表进GoldenGate修复单表需要对同步系统进行重新某个表内数据不一致时，就需要使行重新同步，且同步过程对业务无影响。 配置，同时同步过程要调用Export/Import工具，用该功能，很明显，因为同步一张容易导致数据库锁定和业务异常。 表就影响整个业务系统是不应该的。 安装配置简易性:绿色安装，无须停业务 安装配置简易性:可能要重启系统 安装过程是否方便，从另外一个侧DSG RealSync是绿色软件，安装上即可使用，Goldengate需要严格的patch包，需要安装编译面反映了软件的成熟度和智能化。 安装过程对业务无影响。 工具环境等； 要求打开oracle的 supplemental log日志，将大量增加archvie log的量。 由于修改参数以及补丁包，将可能要求生产系统重启 第 6 页 共 8 页
PK/UK依赖性: 无 PK/UK依赖性: 严重 客户根据业务需求来配置PK/UK，DSG RealSync的运行和效率与容灾数据库表在同样的环境中测试，目标端没有PK/UK的表在一个成熟的数据库中，必然有一是否有PK/UK完全无关。 比有PK/UK的表效率低7-10倍。由于GoldenGate些表是没有PK/UK的。由于这些DSG RealSync也有与其他公司一样的依赖需要借助PK/UK来锁定和验证数据一致性，因表的存在，可能导致数据库的整体PK/UK的版本。 日志分析性能 日志分析性能 如果日志分析速度慢，容易发生日此，同步过程中经常导致目标端锁定。 容灾性能大幅下降。 从大量的应用情况来看DSG RealSync在处同样在福建电信的项目中，GoldenGate的日志志分析跟不上日志切换速度的问理性能上优于同类方案。 分析速度远远低于Realsync的日志分析速度。 题，导致丢失同步。越在业务高峰在福建电信项目中采取了积压日志分析的方所以在本项目中，客户最终选择了DSG 期，越容易发生此类现象，导致需式进行测试，预先产生4GB的日志数据，然RealSync软件。 要重新进行数据同步。 后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名，在800秒内产生的4GB日志，realsync只需要100秒分钟即能分析完累积的日志，其速度远远高于产生日志的速度。 目标装载性能 目标装载性能 目标端装载越慢，说明数据的延迟从大量的应用情况来看DSG RealSync在装同样的测试环境中，GoldenGate厂商需要1600时间越长，在主业务系统出现故障载速度上优于同类方案。 第 7 页 共 8 页
在福建电信项目采取了并发交易测试方法进秒才能完成，比DSG RealSync慢一般左右。 行测试，预先产生7GB的日志数据，然后启动realsync测试其在多长时间内能够装载完所有操作。测试结果表名，DSG RealSync是业界最快的，在1100秒装完了所有数据 复制对象配置是否简单: 简单 复制对象配置是否简单: 复杂 后，系统能够接管的时间间隔越长，也就是RTO指标越差。如果延迟时间超过半小时，采用数据库容灾就没有任何意义。 必须考虑到，这样的配置可能随业务系统的升级而需要重新配置，工作量可想而知，如果配置出现问题，将会导致后续同步中的一系列错误和不一致。 DSG Realsync在配置需要复制的对象时具有GoldenGate在配置上，需要为每个table设置映非常灵活的方式，包括： 射关系，同时需要考虑表与表之间的约束关系，需要复制的schmea 不需要复制的schmea 必须将主外键表放在一个同步组中，试想一下在需要复制的所有tables 一个具有几千张上万张表的情况，如何快速的配不需要复制的所有tables 置这么多的表呢？ 数据压缩率:20倍以上 数据压缩率:8-9倍 在远程网络传输过程中的数据压在相同环境下，DSG RealSync同步过程中传在相同环境下，GoldenGate只能实现8-9倍的数缩率非常关键。压缩率增加1倍，输的数据量是日志产生量的1/20以下。即数据据压缩率。 库每产生10GB的日志，在网络上只需要传递512MB的数据。针对不同的数据操作类型，压缩率更能更高。
意味着客户可能可节省一半的网络费用。 第 8 页 共 8 页