学习streams第二天

使用oracle streams 

 

oracle streams的优势：可以在不同的硬件平台和oracle数据库版本之间复制数据。这个特性保证不同的硬件平台之间的数据库迁移只需要很少的甚至不需要停工时间，并且不会有数据丢失。这个特性还简化了数据库，平台和应用程序的升级过程不必停工。

1.数据复制

oracle streams简化了对象以及其数据在多个数据库之间的共享。对任意一个数据库中对象所做的修改可以传播到所有其他参与复制的数据库。oracle streams可以捕获并复制对表所做的ddl和dml修改。可以在数据库层、模式层、数据表层，甚至是在数据子集上配置对这些修改的复制。

当表的结构或者数据类型不同时，oracle streams支持复制数据到表中。在复制过程中，可以对模式、表或列重命名，也可以增加或删除任意组件(捕获组件、传输组件和应用组件)中的列。

1.1.单向复制

单向复制可能是oracle streams复制中使用最广的方法，同时也是最容易配置的复制环境。需要两个数据库参与单向复制：一个数据库作为源数据库，另一个作为目标数据库。对源数据库所做的修改将被复制到目标数据库中。如下图，用户应用程序对数据库A中的数据做了修改，这些修改会传播并应用到数据库B，以只读方式访问数据库B的应用程序可以得到该数据。

 对于经常使用但资源消耗比较大的只读操作，如复杂的查询或者报告作业，当需要把他们产生的负载分流带另一个数据库服务器时，这个配置很合适。

目标数据库不允许对复制表进行修改。只有应用用户，通常是streams管理员，才可以将复制的修改应用到这些表中。应用程序和用户可以修改本地的任何非复制表。

当对整个源数据库进行单向复制时，其配置可能与oracle data guard的逻辑备用数据库相似。但是与逻辑备用数据库不同的是，streams复制的数据库时以读-写模式公开的，并且对在复制数据库上运行的应用程序提供准实时数据。oracle database 11g data guard中有一个叫做“活动备用数据库”的新选项，也在数据库应用修改时为应用程序提供了类似的实时数据。但是活动备用数据库不能为应用程序提供任何读-写模式的表。

1.2.双向复制

在两个数据库参与复制的环境中，可以修改其中任意一个数据库，然后将修改复制到另一个数据库。两个数据库都捕获本地的修改并且将这些修改传播到另一个数据库中运行的应用进程。这叫双向复制。 其实就是两个数据库之间的单向streams复制活动的两个实例。

 当需要保持本地数据库中的数据更容易被用户和应用程序访问的时候，这个配置很适合。这个配置也可以用户创建一个灾难恢复站点，以主动/主动或zhudong/被动方式服务于那些数据库。

在双向复制中，可以在两个数据库中同事修改相同的数据。这样的修改会在另一个数据库的应用进程应用修改时导致数据冲突发生。这会导致一个应用错误发生。为了避免这样的错误发生，需要实现更新冲突处理存储过程。理想状态下，应该在应用程序设计时尽可能减少或排除数据冲突。oracle提供了一些类型的冲突处理程序。如果这些不足以解决冲突，可以自定义存储过程。此外，需要使用streams标签以避免循环修改。

1.3.点对点复制

可以将点对点复制看作是双向复制的扩展。在这个配置中，需要两个以上的数据库参与。每个数据库都是其他每个数据库的源并且将本地修改传播到其他所有数据库中。每个数据库都是所有其他数据库的目标数据库并且应用来自其他数据库的修改。使用streams标签，修改不会再发送给源数据库。

 当数据以分布式保存在多于两个的数据库中，但是应用程序和用户需要一个统一的数据视图时，该配置很适合。

和双向复制类似，点对点复制也需要适当的冲突处理存储过程以及用于避免循环修改的streams标签。

1.4.辐射型复制

当数据需要从一个主数据库复制到其他多个从数据库，可以使用oracle streams提供的辐射型复制配置。

在一个辐射型复制配置中，一个主数据库维护与其他所有数据库的连接。主数据库作为中心，其他的数据库作为支线。每个支线数据库不直接和其他支线数据库通信。在单个支线之间没有连接，所有的信息都需要从这个架构的中心通过。

1.4.1只读型支线

在这种情况下，中心或者主数据库把本地的修改复制到所有的支线数据库中。支线数据库不修改复制对象。单个中心-支线的辐射型复制配置和单向复制类似。

1.4.2.读-写型支线

在这种情况下，中心数据库和所有的支线数据库都可以修改复制对象。这些修改通过中心数据库复制到剩余的数据库中。支线数据库捕获本地修改并且将这些修改传播到中心数据库中。中心数据库应用这些修改，然后重新捕获这些修改并将其传播到剩余的支线数据库中。

中心数据库中的捕捉进程捕获本地的修改以及由这些支线数据库产生的修改，然后将捕获的修改传播到相应的支线数据库中。需要使用streams标签以确保修改不会发送回支线数据库。

此外，也可以将中心数据库配置为传播中心，从而将一个支线数据库中的修改转发的其他的支线数据库中。中心数据库不会在本地应用这些修改或捕获任何本地修改。这是一个实现点对点复制的队列转发的示例。

这种点对点复制避免了需要连接每一个数据库到其他所有的数据库来辅助数据的负载型。

1.5.与非oracle数据库的复制

oracle streams提供了再oracle和非oracle数据库之间分享消息的机制。oracle 11g r2采用一个新的称作 XSTREAM的API来将数据发送到oracle数据库并接收来自oracle数据库的数据。这个API允许oracle数据库和其他系统之间共享信息。其他系统可以是非oracle 数据库、文件系统甚至是客户端应用程序。XStream接口基于oracle stream基础设施构建而成，并且提供和oracle streams同样的灵活性和功能。不过，XStream是作为一个附加的数据库选项并且需要单独授权。

2.数据仓库加载

数据仓库或者数据集市已经成很多业务不可分割的一部分。这些数据库中的数据维护包括更新已有数据以及从事务和操作数据库中添加更多的数据。通常，这些操作都是一些常规操作并且非常耗时。由于这些数据都是很多从其他数据库复制得来，因此这可以看做另一种形式的数据复制。

可以使用oracle streams来捕获对操作数据库所做做的修改。这些修改可以在处理和应用到数据仓库之前存储在一个中间数据库中。这样做可以避免阶段性的数据提取过程。

oracle streams也可以直接将这些修改应用到数据仓库的目标表中，以保证那些表中的数据是最新的。

oracle streams提供了转换、重新格式化和修改数据的灵活性，以满足数据仓库应用程序对数据的要求。这有助于屏蔽操作表和数据仓库表之间的差异，便于数据仓库表中数据的加载。很多的数据转换，比如long到lob的转换，都由oracle streams自动完成。用户自定义转换也可以在数据加载时进行配置。

1.3.数据审计

可以将oracle streams配置成一个审计机制来跟踪数据的修改。在这种模式下，不是去复制数据，而是简单的捕获数据的修改。由于可以灵活控制需要捕获的信息，oracle streams提供了一个简单而有效的解决方案来跟踪和监视敏感及关键数据的修改。

可以使用DML LCR中的信息来审计DML修改。除了模式、表、列名以及列的旧值和新值之外，还可以在LCR中包含额外的信息，比如收到影响的行号、进行修改操作的用户名以及修改发生位置的序列号和会话编号。这些信息可以很容易的从LCR中抽取，并且存储在自己的审计表中。

跟踪和报告由DBA对数据库所做的DDL自改难度较大，尤其是在缺乏严格的代码控制机制时。在很多情况下，很少的DBA需要维护大量的数据库，因为难度很大。可以配置oracle streams，使之仅仅捕获ddl修改并且将其传播到其他的作为ddl审计容器的数据库中。DDL LCR提供用于识别源数据库、受影响的对象名以及修改的具体时间所需的所有信息。通过在LCR中包含额外的信息，也可以捕获进行修改操作的用户名以及修改发生位置的序列号和会话编号。

1.4.数据保护

使用oracle streams可以创建产品数据库的一个远程副本，这个副本叫做复制数据库而不是备用数据库。复制数据库是针对产品数据库的一个准实时镜像，并且允许读/写访问。产品数据库上的修改会复制到复制数据库上。当主数据库不可用时，可以命令应用程序使用复制数据库。使用双向streams复制功能，原产品数据库一旦可用，就可以立即将复制数据库中的数据与原产屏数据库同步。这样的配置可以为业务连续性提供所需的数据保护。

1.5.消息队列管理

oracle streams的高级队列管理(Advanced Queuing，AQ)组件是一个整合的消息基础设施，支持消息队列管理系统的所有标准特性。

oracle streams AQ允许消息从一个队列传播到本地同一数据库或者是远程数据库的另一个队列中，这使得应用程序可以在分布式环境中进行异步通信。oracle streams AQ的一个重要特性是提供了对消息的事务性支持。应用程序可以在单个事务中管理数据和消息。

oracle streams AQ允许在数据库中创建队列，支持对这些队列使用点对点模型和发布-订阅(或多消费者)模型。

可以配置这些队列，使他们支持某种特殊的消息类型或者是ANYDATA类型。实际使用中的所有消息类型都可以封装到ANYDATA封装器中。一旦创建，用户应用程序就可以向队列中插入消息。之后，消息会传播到订阅队列。用户应用程序在收到消息已经到达的通知后，从队列中取出消息。这些队列在内部的数据库队列中得到持续保存。这些表中的一行对应队列中相应的一个消息。

oracle streams AQ允许消息基于消息内容进行路由，此外还支持基于规则的内容进行路由。oracle streams AQ系统支持消息转换，可以在消息发送给订阅者之前转换消息格式。

1.6.在数据库升级时减少停工时间

当新的oracle数据库版本发布时，对于老版本最终将不再支持。虽然应用程序可能还无法利用新版本中提供的新的或是改进的特性，但是数据库还是需要更新到新版本以保证得到支持。在升级过程中，旧版本的数据库被转换到新版本。通常会推荐在升级之前进行一次历险的数据库备份。

oracle streams可以很大程度上减少甚至在某些情况下排除数据库听过时间，而不管数据库升级需要多少时间。

在这种情况下，首先需要使用streams配置一个单源(single-source)的单向复制环境。首先，需要创建一个和当前源数据库版本一样的空目标数据库。然后，需要配置他们之间的数据库级别的streams复制。应用程序继续使用当前源数据库。接下来停止源数据库的捕获进程，复制被挂起，目标数据库则被升级。一旦目标数据库完成升级，复制就恢复。所有在此期间对源数据库的修改都将被复制到目标数据库。一旦目标数据库和源数据库一致，就将源数据库下限，并转换应用程序使之使用目标数据库。可以删除目标数据库的streams配置。

1.7.在进行维护工作时减少停工时间

小结：

Oracle Streams为数据复制需求提供了一个多用途的解决方案，可以用户多个不同的复制场景。但是，数据复制并不是oraclestreams的唯一应用。oracle streams的灵活且易配置环境，使得它可以为很多不同的业务需求捕获数据修改。由于可以从重做日志和归档日志中捕获数据库修改并且在不同额硬件平台和oracle版本之间复制这些吸怪，oracle streams可以在进行数据库迁移和升级时减少或者排除停工时间。

oracle streams AQ组件提供了一个整合的消息基础设施。除了标准的消息管理特性之外，他还提供对消息的事务性支持。应用程序可以在单个事务管理中管理数据和消息。