Stream结构的设计与规划

    在单源复制结构中，stream结构的设计与规划，不需要考虑标识冲突，比如源库中对象的唯一索引或主键将解决此类问题；在多源复制结构中，stream结构的设计与规划，不仅要考虑数据延迟问题，还要考虑系统性能、递归传播、标识冲突等问题。

    新系统在设计时考虑将来是否有数据复制需求，如果存在数据复制需求，首先要考虑标识的冲突问题；然后要为满足性能问题提供可行性方案（比如归档切换较频繁，捕获与传播进程的工作较重），如果参与复制的产品库较多，性能问题就很关键，如果新系统上线后不久就要升级服务器的配置或更换存储设备，那对24x7的系统是很难接受的。

    某连锁超市系统每天在总部都有很多业务数据下发到连锁门店，而连锁门店系统每天也有很多销售流水要上传到总部，下发与上传数据延迟时间要求小于30分钟，对于这个案例，如何设计数据库物理结构呢？

    对于标识冲突问题，常用的有两种解决方式：一种是用全局唯一标识（GUID）做主键，一种是序列生成的流水号与门店编号组合做主键；这两种方式都很简单实用，后者在存储上占用较少的空间，也意味着更少的网络流量需求。

    对于复制性能问题，首先关注系统的物理结构设计，总部与门店表结构设计必须简洁，如果连锁门店的数目较多，对产品库服务器的压力将会很大，所以对系统中参与复制的表，要区分主次关系，将表中更新频繁的字段规划到一个表，不频繁的字段规划到一起，这样就可以减少一些不必要的流量；尽量避免系统中参与复制的表中使用lob字段，尽量减少表中的冗余字段，减少数据冗余。

    其次需要认真分析企业将来的发展形势，设计出可扩展的复制架构，在10gR1以后的版本中，stream可以配置downstream 数据库，用于处理总部系统的数据下发以及门店的上传数据，由于downstream数据库是独立主机与存储（低端），它可以利用较少的硬件投资，达到良好的复制性能。

    最后，如何最大限度减少数据传播延迟呢？在不考虑网络问题的情况下，焦点集中在产品库与downstream库之间的归档传送上，如果downstream库能很快接收来自产品库的归档，在downstream库的日志挖掘与数据下发将不是问题，如果挖掘速度不够的话，可以通过配置logmnr_max_persistent_sessions参数来增加挖掘进程的数量，这会消耗更多的内存，10gR2中downstream可以接收主库的online redo log减少数据延迟。

    如何提高产品库到downstream库的归档日志传送呢？可以采取较小的日志组，当然也可以通过配置archive_lag_target参数来限制产品库日志切换的时间，archive_lag_target参数如果设置太小，产生库的日志切换将很频繁，当然会影响生产库的性能，该参数取值在900秒左右，基本上就可以保证复制方案的要求。

    如果旧系统需要配置stream复制，不仅要考虑以上这些问题，还要考虑到目标库的数据同步问题，对于24x7的产品库来讲，如果产品库较大，那目标库数据同步的难度就较大，在10gR1中，提供了很多种目标库数据同步的方法，比如data pumb exp/imp、rman等，都可以帮我们做到目标库初始数据的同步。

    但旧系统的麻烦不止这些，如果产品库运行的是外购的软件产品，那就很难要求软件供应商根据你的需求对产品进行大的改动，只要开动脑筋，肯定可以找到解决方案的，有丰富经验的构架师与数据库管理员，是确保stream成功的前提。

    在stream复制配置过程中，产品库减少中间环节，在没有性能恶化的状态下，可以不采用downstream库来减少数据复制的延迟时间；在有性能恶化的状态下，产品库需增加中间环节，即downstream来减轻产品库的压力，结果以数据延迟时间为代价的。

    Stream在10gR1的新特征

10gR1中stream replication的新特征主要集中在五个方面：stream性能、stream配置与管理、stream replication、stream messaging以及rule interfaces等，这些功能的增强，使stream replication在企业数据复制市场有更大作为。

    在rac方面的改进

    在9i rac中，捕获（capture ）进程只能从rac各节点的archived redo log中进行捕获符合rule set定义的事务及操作；在10gR1中，捕获进程可以从rac各节点的online redo log中进行捕获符合rule set定义的事务及操作，极大地降低了传播延迟；如果某实例上的捕获或应用进程宕掉，另一实例将会接管它的队列。

    downstream的应用

    在9i中，捕获进程只能在本地进行对日志进行挖掘，如果redo log文件比较大或redo log切换较频繁，日志挖掘对生产库的资源占用就较多；在10gR1中，捕获进程可以在远程数据库上进行归档日志挖掘，归档日志通过日志传送服务传送。如下图3所示：

图3 远程捕获

    Stream pool的变化

    在10gR1中，新增的stream_pool_size参数设置分配给stream的内存，它从sga中分配，建议stream pool不要小于200m；在10gR1以前的版本中，stream pool从shared_pool_size中分配，shared pool的10%分配给stream pool使用，如果shared_pool_size较小，stream的一些进程因内存不足而宕掉。如图4所示：

图4 内存结构

    支持IOT（index-organized table）及FBI（function-base index）

    在10gR1中，获捕或应用进程支持IOT及FBI，以及其它的一些数据类型（nclob、binary_float、binary_double、long、long raw）等，LCRs可以容纳这些数据类型并被传播进程传播到目标数据库。

    拷贝与移动表空间

    在10gR1中，用dbms_streams_tablespace_adm可以在两个数据库间移动或拷贝表空间，它在底层用是transportable tablespaces、data pump及dbms_file_transfer。

    清除stream replication环境

    在9iR2中，若要清除stream环境，是很较复杂的过程，很可能在数据字典中留下一些垃圾；在10gR1中，清除stream环境，调用dbms_streams_adm的remove_streams_configuration过程；清除stream环境后，想删除stream queue，可调用dbms_streams_adm的remove_queue过程，该过程有个cascade参数，当该参数为true时，将会清除所有的queue信息。

    增强的数据初始化方法

    在9iR2中，只能用exp/imp来初始化源库与目标库的数据一致；在10gR1中，可以用data pump exp/imp、rman、transportable tablespace来初始源库与目标库的数据一致。

    sysaux表空间的变化

    在10gR1中，已经将logminer默认表空间从system迁移到sysaux表空间，不需要像9iR2中调用dbms_logmnr_d的set_tablespace过程，如果执行set_tablespace将logminer默认的表空间移动到其它的表空间，将会导致一些索引失效，好在10gR1中已经可以跟踪失效的索引，并自动对系统的索引进行重建。

    在重做日志中建立数据字典

    在10gR1中，可以用dbms_capture_adm的build过程从当前的数据库中抽取数据字典到重做日志中，捕获进程可以利用redo log中的数据字典创建logminer需要的数据字典，该过程的参数fisrt_scn可以传入一个被捕获进程使用的系统改变号，捕获进程从redo log中捕获的改变将从first_scn开始，也可重置捕获进程的first_scn来清除logminer数据字典中非必须信息。

    迁移advanced replication到stream replication的脚本

    在10gR1中，stream replication的功能与稳定性都有了很大的提高，oracle为了方便用户将现有的advanced replication方案迁移到stream replication，还编写了方便用户迁移的脚本，只需要调用dbms_repcat的streams_migration过程即可。

    简化的消息管理

    在10gR1中，stream replication中提供了dbms_streams_messaging来入队列（enqueue）与出队列（dequeue）消息，过程euqueue直需把sys.anydata类型实参代入，就可以打包成LCRs入队列，在目标库中，过程dequeue则可以取出解包后的sys.anydata的值；dbms_streams_adm的过程add_message_propagation_rule可以为消息传播添加rule。

    简化的stream授权

    在10gR1中之前的版本，stream管理员需要授予很多必需的权限；但在10gR1中，则只需要授予dba权限却可满足stream的要求；另外，新的工具包dbms_streams_auth提供的过程使stream的授权更加简单。

    stream环境的时间点恢复过程（get_scn_mapping）

    在10gR1的多源复制环境中，当某个源数据库执行不完全恢复（基于时间点恢复）后，可以用dbms_streams_adm的get_scn_mapping过程，获取源数据库捕获进程的scn值，然后目标数据库应用进程对源库进行事务恢复。

    访问buffered queue信息

    在10gR1中，队列缓冲区信息可以通过新增的动态性能视图（v$buffered_subscribers、v$buffered_publishers、v$buffered_queue）来访问，分配自sga的stream pool仅存储捕获进程捕获的events，user-enquened LCR events或user-enquened non-LCR events不存入stream pool而存储在一个queue表（实际上是写入disk），捕获进程捕获的events在stream pool中超过一定的时间或者没有足够内存时，也会存入queue表（写入Disk）。