注：因为Logical Standby受支持数据类型，以及日志分析效率等影响很少用于实际应用，所以这里不做比较。以下比较的均为Physical Standby
（1）DataGuard 的异步模式是将Archived Redo Log从源数据库异步的写到备份数据库，完成容灾工作，由于传输的是归档日志，所以这种方式存在的潜在风险是如果生产系统出现问题，会导致最后一个日志无法完成归档，这样这个日志中的数据无法加载到容灾端数据库，结果可能造成损失十几分钟或者几十分钟的数据，由此可以看到采用此种方式RPO>10分钟，对于存放关键数据的应用这么长时间的数据丢失显然是不允许的。
（2）DataGuard 可以支持同步的模式，如果采用同步的模式，事务提交的前提是redo data必须写入本地online log及至少一个standby log，如果没有满足这个条件，则该事务不能提交，这就表示生产端与容灾端之间的网络链路要绝对可靠，如果生产端与容灾端之间的网络一旦出现问题，必然会导致生产系统down机，而且使用这种模式比较消耗系统资源，所以很多使用DataGuard的应用中均采用异步方式。
（3）不论是同步模式还是异步模式，DataGuard传输的都是redo log如果对于每天日志量比较大，带宽有限的异地应用，由于异地容灾租用带宽成本很高，根据我们的经验，现有的跨省容灾项目带宽一般为2M,如果采用DataGuard方式传输归档日志，根本无法及时将每天的归档日志传输到目标端。造成生产端与容灾端数据存在大量的数据延迟。虽然本项目目前是同城容灾，不过现在异地容灾已经是大势所趋，所以即使是目前的同城容灾，这个问题也应该提前考虑的。
（4）不论是同步模式还是异步模式,容灾端数据库都只能配置成物理备用库,众所周知,物理库用库通常在managed recover状态是不能提供查询的,如果想提供查询,就必须在open read only状态，显然不能满足实时查询的要求，并且在open read only状态时,即使可以继续传输归档日志，但是是不可以再进行即时归档恢复,如果这种情况下生产端数据库出现问题，容灾端数据库显然不能立刻接管业务，必须将open read only这段时间生产端传送过来的日志进行加载。加载完后将数据库open后才能对外提供应用。数据库open的时间跟数据量的大小也是相关的，数据量越大open的时间相对越长，而且可能存在数据库不能正常打开的可能。
(5)监控DataGuard是否工作正常只能通过查看Oracle的Alert.log或者V$视图比较繁琐，不容易即时发现和解决复制过程中的问题，
RealSyn技术与DataGuard技术的比较
|
DSG RealSync |
ORACLE DG |
|
u 适合对象：
¨ 适合从工作组级、企业级到数据中心级的复制需求。
¨ 无论系统采用什么样的服务器平台、什么样的存储平台，只要是ORACLE系统之间的复制即可适用。
u 优点：
ü ¨ 目标端数据可用：目标端数据库在复制过程中出于可用状态，可用作数据查询、报表、数据抽取等任务分担；
ü ¨ 异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台；
ü ¨ 支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间，提高应用灵活性；
ü ¨ 支持1对多，多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。
ü ¨ 节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。
ü ¨ 性能高于ORACLE DG，DSG RealSync软件已经应用于广西移动的营帐系统的环境，数据容量达到2TB，每天产生的日志量最大能够处理到600GB/天
u 缺点：
ü ¨ 需要单独购买
ü ¨ 只支持异步复制，不支持同步方式。 |
u 适合对象：
¨ 主要适用于几十GB的小型数据库的容灾使用。
u 优点：
ü ¨ Free
ü ¨ 可实现同步复制模式。
u 缺点：
ü ¨ 目标端数据不可用：目标端数据库在复制过程中处于RECOVER状态，不能被用来使用；
ü ¨ 操作系统必需同构：源和目标必需要求相同的操作系统和相同的数据库版本；
ü ¨ 只能全库复制：复制的对象是整个数据库
ü ¨ 不能实现数据整合和数据分发；
ü ¨ 性能低下，目前的应用案例多在几十GB的小型数据库上使用。
ü ¨ 重新同步一次非常复杂，需要通过备份恢复的方式来进行首次初始化，并且最好很死停止业务。
ü ¨ logical standby模式的性能低下
ü ¨ logical standby方式支持的数据类型有限，例如对long raw，rowid等数据类型不支持。 |
从性能上来比较，也有较大差别：
总结二者对比的明显优势
1.3.1 目标端数据库可用
Oracle DataGuard的Physical Standby模式目标端数据库目标端数据不可用：目标端数据库在复制过程中处于RECOVER状态，不能被用来使用，这样只有容灾端数据库只能起到容灾的作用，从而造成机器设备的浪费。而且由于目标端数据库并不是open状态的，当源端数据库出现问题时整个切换过程要包括数据库启动和应用程序切换，且数据库启动过程中可能会由于日志错误造成数据库无法启动。
由于DSG RealSync实时分析Oracle的在线日志，将分析的结果转换成sql语句在目标端进行加载，目标段数据库处于open的状态，这样当源端数据库出现问题时，这样整个切换时间只是应用层的切换时间，从而有效的保证了切换时间最短，这样目标端数据库不仅可以用来容灾还可以用来将OLTP应用、报表和查询应用分离；提高每个系统效率，降低资源争用和消耗，从而更有效的利用现有设备。
1.3.2 DSG RealSync实时分析Oracle的在线日志
Oracle DataGuard的Physical Standby是通过源端向目标端传送归档日志实现数据库的同步复制，这样只有归档的日志文件才能被传送到实时备份数据库上，这样一旦源端数据库出现问题，所有的在线日志中数据将全同丢失，这样将丢失十几分钟乃至更长时间的数据。这显然是无法令人满意的。
DSG RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源端系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。
根据实际的应用案例，我们发现在源端采用RAC方式，两个Instance并发装载20万条记录的情况下，在源端的数据产生速度>2000条/s的情况下，复制延迟时间为10秒以内。
1.3.3 DSG RealSync在日志分析速度上非常好
Oracle DataGuard还有另外一种应用很少的方式Logical Standby，这种方式类似于DSG RealSync也是一种异步准实时的复制技术，它同样是分析Oracle的在线日志，将在线日志转换为sql语句在目标端装载，Oracle DataGuard的Logical Standby配置繁琐，维护工作量很大，这种模式使用logminer来进行日志的分析，而logminer在日志分析速度上是有瓶颈的，而且使用logminer分析日志会消耗大量的cpu、内存、IO，而且logminer不支持BLOB和CLOB等数据类型。
针对logminer的缺陷，DSG重新开发了ologx日志分析工具，根据实际的工程运行数据,在10分钟内产生800万条记录，realsync只需要2分钟即能分析完累积的日志，其速度远远高于产生日志的速度。完全能够满足电信级业务需求，即使是在业务高峰期，也不会造成日志累积。例如某移动项目约每天切换260组日志，每组日志660M,一天约170G日志量，RealSync的分析速度完全可以跟上。
在正常情况下，DSG RealSync每天能够分析处理的日志量能达到300-400GB.（这与实际的硬件环境有关）
另外目前DSG RealSync支持几乎全部Oracle数据类型，以及所有Oracle的DDL操作。
1.3.4 DSG RealSync资源占用上不会对系统造成压力。
DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为几个百分点。
根据移动行业的应用案例显示，在源端每分钟分析2OOM日志的情况下，DSG RealSync对CPU的占用上平均为单个cpu的5%。
因为REALSYNC采用单进程方式运行，所以一个复制任务最多占用一个CPU，在未来的多任务下，最多使用2个CPU。相对于源端多个CPU的处理能力，RealSync不会对系统造成压力。
1.3.5 DSG RealSync源端无需停机就可以完成初始化配置
Oracle DataGuard初始化配置必须要求源端停机然后进行一个冷备用来初始化目标端的环境，这样如果实时同步过程中由于网络等其它问题造成复制中段就必须重新进行一个冷备以完成源端和目标端的初始化工作，因此使用过程中维护工作非常繁重。
DSG RealSync提供了不需要停机的首次快速全同步功能，该功能支持数据库在正常业务不中断的情况下将源端所有数据包括对象导入到目标端数据库。从而避免了一些类似复制方案要求首次同步生产系统必须停机以保证数据一致性，这种操作对于7×24小时的生产系统肯定是有影响的。另外RealSync的首次全同步功能直接通过底层进行数据的导出和装载，并且导出过程中只导出表空间中使用的数据，源端的数据导出速度在2－3G/分钟左右，装载速度在1-1.5G/分钟左右(此数据可能因主机和盘阵的性能而稍有差异)，导出数据自动传输到目标端，传输过程中采用DSG特有的压缩算法，压缩比一般在75％左右。
附一：该功能与物理拷贝方式（磁盘对拷、RMAN COPY、备份恢复）和逻辑方式（ORACLE EXP/IMP）相比具有以下特点：
1、realsync在作全同步时无需停止业务；
2、realsync作全同步的点和日志分析的点自动匹配，无需人为干预。因为如果需要人为干预就必需停止业务，否则无法保证全同步和增量同步之间的无缝衔接；
3、realsync在作全同步时可根据业务灵活调整，如根据业务规则分批进行全同步、而无需一定要在有限的时间内完成整个库的全同步，而是把业务变化最频繁，容灾需求最紧急的数据优先同步；
4、realsync作全同步采用IP网络通讯，对存储的结构无要求，不要求两个存储之间一定要在同一个SAN结构下，或者要求两个存储之间一定要有阵列复制软件；
5、RealSync采用多任务并发方式进行全同步，性能完全能够满足业务需求，如采用8个任务并发，正常情况下可在8小时左右完成1.3TB的数据的全同步（该数据为有效的记录数据，而不是数据库分配大小）；
6、realsync支持源系统和目标系统之间的OS系统、存储系统、数据库版本不相同；
1.3.6 较低的网络资源使用
由于RealSync不是向目标端传送日志，而是将分析后的日志用压缩的xf1文件格式传送到目标端，这意味着RealSync在网络中传输的数据量远远小于系统生成的日志数量。
由于oracle的日志是格式化的数据块，数据块中包含一部分格式信息，这些格式化信息占必然会占用一部分空间。
进行insert数据时，oracle的日志不光记录插入数据，如果该插入数据的表中包含索引字段，oracle的日志同样会记录这些索引字段的插入操作，RealSync只抓取插入数据操作，并不理会插入索引的操作，如果一个表索引越多，日志里实际对于RealSync有用的信息就越少，这样抓出的xf1文件相对于原日志量也会越少。
进行update操作时，oracle的日志会记录下update操作前进行更新字段的值和更新后字段的值，RealSync只抓取更新后字段的值。如果更新的是索引字段的话，日志中的无用信息会更多。
根据实际测试对于100M的日志分析后生成的xf1文件累计只有20M大小，对于只有一个索引的表进行insert、update和delete操作。加上对于增量数据的75％的压缩，这样100M的日志最后需要传输的只有5M左右。
1.3.7 基于CRC算法的快速的一致性比较
对于各种类型的复制软件数据一致性是用户比较关注的问题，因此是否有简单快速的进行数据一致性的检查的工具尤为重要。DSG RealSync提供了一个性能很高的一致性比较工具，该工具的工作方式不是通过select接口读取数据进行比较，而是通过其快速导出工具进行记录导出，并将导出的记录分别形成CRC校验码，然后通过CRC校验码来检验数据是否一致。从测试来看这种方式存在许多优点：
1、性能高：对一个有900多万行记录的用户进行一致性比较，比较时间<1分钟；
2、对特殊数据类型也可以比较：对于long raw,lob等类型都可以比较。
3、网络压力小：因为传输的数据不是记录本身，而只是每条记录的crc校验码，因此网络压力很小。
1.3.8 简易灾难恢复流程
在生产数据库系统发生灾难的情况下，此时可使用容灾数据库首先接管业务，然后进行数据的反向恢复。具体步骤为：
（1） 生产数据发生灾难，生产端业务停止；
（2） 修改TNS的指向，将数据库指向灾备中心的数据库；
（3） 应用系统重新连接灾备数据库，完成业务接管；
（4） 排除生产系统的故障；
（5） 启动生产系统的oracle数据库
（6） 反向恢复生产系统数据
（7） 修改TNS指向，将数据库指向生产中心的数据库；
（8） 应用系统重新连接生产中心数据库，完成业务回切；
（9） 配置realsync进行正向复制；
1.3.9 国内设研发服务机构，随时响应客户需求
数据复制容灾系统在业务连续性中是非常关键的，这种系统的建设不是单纯的产品购买问题，而是涉及深入到应用系统逻辑的支持。对于数据复制系统上的后期支持，以及针对新业务的开发上都需要有厂商更大的支持。
DSG作为立足国内，面向世界的软件开发商，在国内设有研发中心和技术服务中心，在国内建有完善的售后服务体系。可以针对应用要求提供客户化支持，为该项目未来发展提供不间断的后续支持，提高响应速度。并且在工程实施方面将由DSG公司直接负责，保证了系统建设成功率。
如对于应用会用到的特殊功能，DSG因为在国内有研发机构，因此能够及时响应。
