DSG与DataGuard的比较.doc

Oracle DataGuard实现原理 注：因为Logical Standby受支持数据类型，以及日志分析效率等影响很少用于实际应用，所以这里不做比较。以下比较的均为Physical Standby （1）DataGuard 的异步模式是将Archived Redo Log从源数据库异步的写到备份数据库，事务提交的前提是redo data必须写入本地online log及至少一个standby log，如果没有满足这个条件，则该事务不能提交，配置成物理备用库,众所周知,物理用库通常在managed recover状态是不能提供查询的,如果想提供查询,就必须在open read only状态在open read only状态,即使可以继续传输归档日志，但是是不可以再进行即时归档恢复,DSG RealSync其他一些优势 DSG RealSync在日志分析速度上非常好 Oracle DataGuard还有另外一种应用很少的方式Logical Standby，这种方式类似于DSG RealSync也是一种异步准实时的复制技术，它同样是分析Oracle的在线日志，将在线日志转换为sql语句在目标端装载，Oracle DataGuard的Logical Standby配置繁琐，维护工作量很大，这种模式使用logminer来进行日志的分析，而logminer在日志分析速度上是有瓶颈的，而且使用logminer分析日志会消耗大量的cpu、内存、IO，而且logminer有一些数据类型是不支持的。 针对logminer的缺陷，DSG重新开发了ologx日志分析工具，根据实际的工程运行数据,在10分钟内产生800万条记录，realsync只需要2分钟即能分析完累积的日志，其速度远远高于产生日志的速度。完全能够满足电信级业务需求，即使是在业务高峰期，也不会造成日志累积。例如某移动项目约每天切换390组日志，每组日志1G,一天约390G日志量，RealSync的分析速度完全可以跟上。 在正常情况下，DSG RealSync每天能够分析处理的日志量能达到300-400GB.（这与实际的硬件环境有关） 另外目前DSG RealSync支持几乎全部Oracle数据类型，以及所有Oracle的DDL操作。 DSG RealSync资源占用上不会对系统造成压力。 DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为几个百分点。 根据移动行业的应用案例显示，在源端每分钟分析5OOM日志的情况下，DSG RealSync对CPU的占用上平均为单个cpu的5%。 因为REALSYNC采用单进程方式运行，所以一个复制任务最多占用一个CPU，在未来的多任务下，最多使用2个CPU。相对于源端多个CPU的处理能力，RealSync不会对系统造成压力。 DSG RealSync源端无需停机就可以完成初始化配置 Oracle DataGuard初始化配置必须要求源端停机然后进行一个冷备用来初始化目标端的环境，这样如果实时同步过程中由于网络等其它问题造成复制中段就必须重新进行一个冷备以完成源端和目标端的初始化工作，因此使用过程中维护工作非常繁重。 DSG RealSync提供了不需要停机的首次快速全同步功能，该功能支持数据库在正常业务不中断的情况下将源端所有数据包括对象导入到目标端数据库。从而避免了一些类似复制方案要求首次同步生产系统必须停机以保证数据一致性，这种操作对于7×24小时的生产系统肯定是有影响的。另外RealSync的首次全同步功能直接通过底层进行数据的导出和装载，并且导出过程中只导出表空间中使用的数据，源端的数据导出速度在3－5G/分钟左右，装载速度在1-1.5G/分钟左右(此数据可能因主机和盘阵的性能而稍有差异)，导出数据自动传输到目标端，传输过程中采用DSG特有的压缩算法，压缩比一般在75％左右。 附一：该功能与物理拷贝方式（磁盘对拷、RMAN COPY、备份恢复）和逻辑方式（ORACLE EXP/IMP）相比具有以下特点： realsync在作全同步时无需停止业务； realsync作全同步的点和日志分析的点自动匹配，无需人为干预。因为如果需要人为干预就必需停止业务，否则无法保证全同步和增量同步之间的无缝衔接； realsync在作全同步时可根据业务灵活调整，如根据业务规则分批进行全同步、而无需一定要在有限的时间内完成整个库的全同步，而是把业务变化最频繁，容灾需求最紧急的数据优先同步； realsync作全同步采用IP网络通讯，对存储的结构无要求，不要求两个