oracle数据同步技术

转自：

http://easthome51905758.blog.163.com/blog/static/3824148320114421112268/

 

 

基于Oracle数据库的数据同步技术大体上可分为两类：Oracle自己提供的数据同步技术和第三方厂商提供的数据同步技术。Oracle自己的同步技术有DataGuard，Streams，Advanced Replication和今年刚收购的一款叫做GoldenGate的数据同步软件。第三方厂商的数据同步技术有Quest公司的SharePlex和DSG的RealSync。下面对这些技术逐一进行介绍。

一、DataGuard数据同步技术

DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数据库保持同步。DataGuard提供了三种日志传输（Redo Transport）方式，分别是ARCH传输、LGWR同步传输和LGWR异步传输。在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（Maximum Performance Mode）、最大保护（Maximum Protection Mode）和最大可用（Maximum Availability Mode），其中最大保护模式和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。

最大性能模式：这种模式是默认的数据保护模式，在不影响源数据库性能的条件下提供尽可能高的数据保护等级。在该种模式下，一旦日志数据写到源数据库的联机日志文件，事务即可提交，不必等待日志写到目标数据库，如果网络带宽充足，该种模式可提供类似于最大可用模式的数据保护等级。

最大保护模式：在这种模式下，日志数据必须同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交。这种模式可确保数据零丢失，但代价是源数据库的可用性，一旦日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库将会被关闭。这也是目前市场上唯一的一种可确保数据零丢失的数据同步解决方案。

最大可用模式：这种模式在不牺牲源数据库可用性的条件下提供了尽可能高的数据保护等级。与最大保护模式一样，日志数据需同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交，与最大保护模式不同的是，如果日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库不会被关闭，而是运行在最大性能模式下，待故障解决并将延迟的日志成功应用在目标库上以后，源数据库将会自动回到最大可用模式下。

根据在目标库上日志应用（Log Apply）方式的不同，DataGuard可分为Physical Standby（Redo Apply）和Logical Standby（SQL Apply）两种。

Physical Standby数据库，在这种方式下，目标库通过介质恢复的方式保持与源数据库同步，这种方式支持任何类型的数据对象和数据类型，一些对数据库物理结构的操作如数据文件的添加，删除等也可支持。如果需要，Physical Standby数据库可以只读方式打开，用于报表查询、数据校验等操作，待这些操作完成后再将数据库置于日志应用模式下。

Logical Standby数据库，在这种方式下，目标库处于打开状态，通过LogMiner挖掘从源数据库传输过来的日志，构造成SQL语句，然后在目标库上执行这些SQL，使之与源数据库保持同步。由于数据库处于打开状态，因此可以在SQL Apply更新数据库的同时将原来在源数据库上执行的一些查询、报表等操作放到目标库上来执行，以减轻源数据库的压力，提高其性能。

DataGuard数据同步技术有以下优势：

1） Oracle数据库自身内置的功能，与每个Oracle新版本的新特性（如ASM）都完全兼容，且不需要另外付费；

2） 配置管理较简单，不需要熟悉其他第三方的软件产品；

3） Physical Standby数据库支持任何类型的数据对象和数据类型；

4） Logical Standby数据库处于打开状态，可以在保持数据同步的同时执行查询等操作；

5） 在最大保护模式下，可确保数据的零丢失；

DataGuard数据同步技术的劣势体现在以下几个方面：

1） 由于传输整个日志文件，因此需要较高的网络传输带宽；

2） Physical Standby数据库虽然可以只读方式打开，然后做些查询、报表等操作，但需要停止应用日志，这将使目标库与源数据不能保持同步，如果在此期间源数据库发生故障，将延长切换的时间；

3） Logical Standby数据库不能支持某些特定的数据对象和数据类型；

4） 不支持一对多复制，不支持双向复制，因此无法应用于信息集成的场合；

5） 只能复制整个数据库，不能选择某个schema或表空间进行单独复制；

6） 不支持异构的系统环境，需要相同的操作系统版本和数据库版本；

DataGuard技术是Oracle推荐的用于高可用灾难恢复环境的数据同步技术。

 

二、Streams数据同步技术

Streams是从版本Oracle 9i才开始具有的数据同步功能，是为提高数据库的高可用性和数据的分发和共享功能而设计的，Streams利用高级队列技术，通过用LogMiner挖掘日志文件生成变更的逻辑记录，然后将这些变更应用到目标数据库上，从而实现数据库之间或一个数据库内部的数据同步。

Streams数据同步大致分如下几个步骤：

1） Capture进程分析日志，生成逻辑记录LCR，将其放入一个队列中；

2） Propagation进程将LCR发送到另一个数据库中，通常是目标数据库；

3） 在目标数据库中，Apply进程将LCR应用到目标库，实现数据的同步；

该处理过程的信息流如下图：

在简单的Streams配置中，Capture进程一般位于源数据库，因此叫做Local Capture Process，Capture进程在分析日志后将生成的LCR放入队列中，由Propagation进程将LCR发送到目标库中。这样做的好处是不用在网络上传送整个的日志文件，因此可提高网络传输的效率，但这一般会给源数据库带来较大的压力，影响其性能。

另一种配置是Capture进程位于Downstream数据库中，源数据库只负责将日志文件传送（日志传输方式可为ARCH传输、LGWR同步传输和LGWR异步传输中的任何一种）到Downstream数据库中，所有的Capture操作都在Downstream数据库上完成。这种配置的好处是可以大大降低源数据库的压力，缺点是需要传输整个日志文件，对网络带宽要求较高。

Streams数据同步技术有以下优势：

1） 可支持一对多、多对一和双向复制，可用于数据分发和共享，这是DataGuard所不具备的；

2） 可灵活配置只复制数据库中的一部分对象，如可按Table复制、Schema复制，表空间复制等，并可在复制过程中对数据进行过滤和转换，使之满足不同的需要；

3） 同DataGuard一样，是Oracle内置功能，与每个Oracle新版本的新特性（如ASM）都完全兼容，且不需要额外付费；

4） 可用于异构的操作系统和数据库版本，但有一些限制；

5） 可支持非Oracle数据库和Oracle数据库之间的数据同步；

6） 目标数据库处于打开状态，可以在保持数据同步的同时执行查询等操作，分担源数据库的压力；

Streams数据同步技术有以下缺点：

1） 配置维护较复杂，需要较高的技术水平；

2） 在非Downstream复制中，对源数据库压力较大；如果使用Downstream复制，则增加了配置的复杂性且需要通过网络传输整个日志文件，对网络带宽要求较高；

3） 不能支持某些特定的数据对象和数据类型；

4） 不能保证数据的零丢失；

Oracle公司将Streams技术定位于数据的分发和共享，虽然也可用于高可用的灾难恢复场合，但Oracle推荐使用的灾难恢复技术是DataGuard。

三、Advanced Replication数据同步技术

Advanced Replication配置管理较复杂，且对源数据库性能影响较大，预计在以后的Oracle版本中将可能逐步被Streams技术所取代，故不再对其做过多的介绍。

四、GoldenGate数据同步技术

GoldenGate原来是一家独立的软件厂商的产品，现该产品已被Oracle公司收购，Oracle将GoldenGate软件集成到到其“融合（Fusion）”中间件中，预计以后该产品将与Oracle数据库更紧密地集成。GoldenGate可以用于多种不同的操作系统平台（Unix、Linux、Windows）和多种不同数据库系统（如DB2、Oracle、Infomix、MySQL、Sybase等）之间的数据同步，是一款优秀的数据同步及数据分发产品。

GoldenGate软件需要安装在源数据库服务器和目标数据库服务器上，所需的操作系统资源在10%以下。GoldenGate数据同步的基本原理是由Extract进程读取源数据库的事物日志（Oracle中是redo log），将其中的变更操作（insert、update、delete等）按事务执行的顺序组合在一起，直接将其发送到目标服务其上，或者存放到Trails文件中，然后由Data Pump进程将Trails文件传输到目标服务其上，在目标服务器上Collector进程接收从源服务器传送过来的Trails文件，最后由Replicat进程将Trails文件中的数据装载到目标数据库中，其处理过程如下图：

由于GoldenGate将数据存储到自己的统一格式的Trail文件中，因此可以将Trail文件传送到不同的操作系统，应用在不同的数据库系统上，大大增强其灵活性。另外，由于GoldenGate只收集必要的数据到Trail文件中，且Trail文件可以压缩，因此大大减少通过网络传输的数据量，压缩后传输的数据量通常是日志量的1/4或更少。

GoldenGate有以下优点：

1） 支持异构的操作系统和数据库管理系统，便于客户在不同数据库管理系统和操作系统平台之间的数据同步，这是其核心优势所在；

2） 跟DataGuard传输整个日志文件相比，GoldenGate传输的数据量大大降低，在没有LOB等数据对象的情况下，通常是整个日志文件1/4或更少；

3） 目标数据库处于打开状态，且支持一对多、多对一，双向复制等，也可以选择部分对象进行复制，可满足数据分发和数据集成的需要，减轻源数据库压力；

4） 所占系统资源较少，通常在10%以下；

5） GoldenGate被Oracle公司收购后，预计对Oracle数据库的支持方面会做的更好；

GoldenGate的劣势体现在以下几个方面：

1） 需要支付额外的Liscense费用，通常是一笔不小的支出；

2） 需要在数据库软件外安装一套专门数据同步软件，增加了管理维护的复杂程度；

3） 不能支持某些特定的数据对象和数据类型；

4） 由于数据复制操作独立于数据库管理系统，因此不能确保数据零丢失。

由以上分析可知，GoldenGate用于数据整合，数据共享和分发方面比较合适，至于在高可用的灾难恢复环境中，如果能满足业务的RPO/RTO要求，也不失为一种理想的数据同步解决方案。

 

五、SharePlex数据同步技术

SharePlex是Quest公司开发的用于专门用于Oracle数据库的数据同步软件，可以运行在异构的操作系统平台上和Oracle数据库的不同版本之间。

SharePlex的数据复制原理与GoldenGate类似，需要分别在源数据库服务器和目标数据库服务器上安装SharePlex软件。具体处理过程是：Capture进程分析源数据库的日志文件，抓取所需的数据变更操作，将其存储在SharePlex自己专有的queue文件中，放入到Capture Queue，然后由Read进程对queue文件进行封装处理，将其放入到Export Queue中，由Export进程将queue文件通过网络发送到目标服务器上，目标服务器上的Import进程接收这些queue文件，将其放入到Post Queue中，最后由Post进程将这些queue文件中的变更应用到目标数据库中，其处理流程如下图：

SharePlex数据同步技术的优势有：

1） 支持异构的操作系统平台，便于数据库管理系统的版本升级及操作系统平台切换；

2） 跟DataGuard传输整个日志文件相比，SharePlex传输的数据量大大降低，这点跟GoldenGate差不多；

3） 目标数据库处于打开状态，且支持一对多、多对一，双向复制等配置，也可以选择部分对象进行复制，可满足数据分发和数据集成的需要，减轻源数据库压力，这方面也类似于GoldenGate；

4） 所占系统资源较少，通常在10%以下；

SharePlex数据同步技术的劣势体现在以下几个方面：

1） 需要支付额外的Liscense费用，通常是一笔不小的支出；

2） 需要在数据库软件外安装一套专门数据同步软件，增加了管理维护的复杂程度；

3） 由于数据复制操作独立于数据库管理系统，因此不能确保数据零丢失；

4） 由于是第三方的软件产品，在对某些特定的数据对象、数据类型和Oracle某些新特性如ASM的支持方面不如数据库厂商自己的解决方案；另外，还有一种可能就是如果Oracle对自己的日志格式做些改变或加密，SharePlex将无能为力；

从上述分析可知，SharePlex虽然专用于Oracle数据库同步，但同GoldenGate相比并无明显优势，GoldenGate对异构数据库的支持更是SharePlex所不能比。再者，现在GoldenGate已经被Oracle公司收购，成为了Oracle的嫡系部队，这对SharePlex来说确实是一件不幸的事，关乎生死。

除了上面介绍的这些数据同步技术外，在国内市场上用于Oracle数据同步的产品还有DSG 公司的RealSync软件，RealSync的实现原理及功能与SharePlex基本类似，也是只支持Oracle数据库，也可以跨越不同的操作系统平台。值得一提的是RealSync在目标数据库的数据装载方面，不是通过主键或唯一键来实现数据记录的定位，而是自己维护一个源数据库和目标数据库的数据记录的rowid mapping表，通过rowid来实现记录的定为，因此在数据装载效率方面有不小的提高。