个人关于Stream原理的一些了解,欢迎大家勘误.doc

今天Pinocchio邀我讲讲Stream, 因为我对Stream的了解也很有限，也讲不了什么，于是将我了解的部分关于Stream的知识写下来，供大家参考。本文只讲原理，不涉及配置过程（配置文档从网上可以找到），算是抛砖引玉吧，有谬误之处，请大家指正。 Streams实际上是一种队列技术，通常称为高级队列（advanced queuing）。Streams位于队列结构的顶端，从最本质的角度上说，Streams所指的是一种方法学，它搜集信息，并将它保存在队列中，然后发布给信息流的需求方。Streams技术在容灾上的应用虽然还不是很成熟，但却有着光明的前景。 将Streams技术应用于容灾，从实现原理上来说，与Data Guard的逻辑备用模式可以说是异曲同工。Oracle Streams可以从本地的在线重做日志中捕获数据库的变化，并异步地传输到目标数据库，然后再目标库上应用这些变化。而且Streams针对数据的复制和传输进行了技术上的优化，可以使主备间的数据差异保持在数秒内。实现过程如下图所示： 在主数据库，Streams有一个捕获进程（local capture process）。它的作用就是捕获重做日志中的数据库修改信息（借助了原有的LogMiner技术），并将这些日志信息组织成一个个LCR（logical change record）。LCR实际上就是包含数据库修改信息的以特定格式封装的消息。这些LCR将会组成消息队列，然后向备库发送。LCR可以分为两种：一种是记录单行数据变化或是行中的long、long raw、lob数据类型列的变化，称为Row LCR；另一种是记录数据定义语句对数据库产生的修改，称为DDL LCR。绝大多数的数据库操作都能被捕获进程捕获。但也有部分操作（例如alter session、alter system）捕获进程无法捕获，不过这并不影响数据库中数据的同步。值得注意的是，对于使用了nologging的操作，因为不会产生重做日志，捕获进程是不能捕获到的。所以在做数据同步的时候最好是将数据库设置为force logging模式，这样就能使nologging选项无效。 在备用数据库，也可以配置捕获进程，称为downstream capture process。这种捕获进程有可以分为两类：一类是realtime downstream capture process，能够捕获standby redo log中的数据库修改信息；另一类是archived log downstream capture process，能够从归档日志中捕获数据库修改信息。在oracle10g的Data Guard的最大保护模式中有一个新功能选项称为real-time apply。也就是standby redo log中的日志信息能实时的被应用到备库中，而不是以前的归档后再应用，因此能真正实现主备库数据的实时同步。也许就是应用了类似real-time downstream capture process的技术。 主数据库的变化信息捕获并通过网络传送到备份数据库后，接下来就涉及到一个变化信息的应用的问题。与主库的捕获进程相对应的，在备库有一个应用进程（apply process）。这个进程的作用就是对从主库传送过来的LCR消息队列进行处理。一个应用进程由三部分组成：称为reader server的部分用于将LCR队列解析成一个个事务；称为协调进程（它是oracle的后台进程）的部分负责将事务传递给apply server；最后由apply server将事务直接执行，或是转交给DML和DDL处理器。当使用DML处理器或是DDL处理器时，这些处理器会调用execute成员过程来执行该项事务。 相对于Data Guard,Streams对主备数据库间的数据同步的实现要灵活很多。首先，通过Streams可以对不同操作系统平台不同版本的oracle数据库进行数据同步，而Data Guard则要求主备数据库必须在相同的平台和数据库版本上。其次，Streams的数据复制可以根据实施者的配置有选择的同步某一部分数据，不必进行全库的同步复制。Streams还可以在不同字符集的数据库之间进行，自动进行字符集的转换。使用Streams技术，可以以广播的形式进行消息的分发，从而实现一主对多备的数据库同步。而且它对备库的数目是没有限制的（Data Guard最多只能配置十个备库）。还有就是Streams在进行数据同步的过程中，备库一直是完全打开状态（可读写）的。这就能进一步缩短主库宕机时，备库的业务接管时间。不过，采用Streams进行同步复制的实施（Streams配置比较容易出错，我前一阵子配过两次，都出错了，这段时间开发任务较忙，没