Oracle Streams 10gR2 流复制操作手册
介绍：
1.1简介：
这个文档简单介绍了oracle stream 并且探讨了其技术构架和命名规则。
介绍了常见的监控和故障排除的脚本。
1.2 背景：
oracle streams 可以传递和管理数据，事务和事件存在一个数据库中的一个数据流里面，或者从一个数据库到另一个。这个流路径可以将信息传递到已知的目标端。这个解决方案是一个新的特性比传统的解决方案（捕获和管理事件，然后再共享这些事件到其他的数据库和应用。）功能更强大和更灵活。
1.3 范围和应用：
这篇文档将检查streams环境监控的步骤。这也包含进行问题处理和debug的存储过程和脚本。
1.4 相关的文档：
Streams Replication Administrator’s Guide
Streams Concepts and Administration
2综述：
oracle streams 是一个综合信息集成解决方案。它不仅提供细粒度的控制复制的方式而且可以让用户完全控制从主库到复制库的路径变化。它允许用户建立集中和辐射型的网络结构，并且能够支持多个复制库(askmac.cn)。
Oracle Streams 从在线日志（事务日志）里捕获数据库表的变化和记录复制的细节。有一个专门的UNIX进程（捕获进程），从重做日志中捕捉流特定变化和格式。每一个捕获做为一个事件，称为逻辑变更记录(LCR logical change record)。
规则用于确定哪些更改可以被捕获进程捕获,然后被复制。
LCR 存储在 流队列中并且通过一个标准的数据库连接，传递到远程目标端。传递到远程目标端的LCRs存储在另一个队列中，等待 应用进程 去使用这些队列， 从而应用到目标数据库对应的表上。
高级流数据复制过程的示意图如下所示：
Oracle Streams 提供了3个基础元素来允许用户控制：放入流中的信息、流经过的节点的路由、流经过每个节点所发生的事件、如何终止流。
这个 oracle streams 的构架是非常灵活的。
如上图所示，流包含3个基本的元素：
1、捕获：
通过一个明确的API，来从重做日志或用户信息中捕捉DML或DDL事件。
2、暂留：
用来在2个数据库之间存储和传递事件(askmac.cn)。
3、应用：
通过一个明确的API，在目标数据库或应用程序上应用DML或DDL事件。
2.1捕获：
oracle stream 支持捕获事件（数据库的变化和应用程式生成的消息）到暂留区域中
这些事件在2个方面被捕获。隐式的捕获是服务在源数据上捕获DML和DDL 事件。
显式捕获允许应用程序显式地生成事件，并放置它们到暂留区域。
在隐式捕获中，捕获进程从日志文件中提取和检索变化的数据，或者从当前的联机日志文件中提取，如果必要的话还可以从归档中提取。在检索数据之后，抽取进程固定将格式固定到LCR中，并将其放置到暂留区域等待进一步处理。捕获进程能够智能地，以定义好的规则来过滤LRCs。因此，只有那些被需求的对象的改变被捕获。
用户的应用程序可以显示的将用户消息，用事件的形式展现在暂留区域中。这些消息可以以LCRs格式化，
而后被应用引擎所使用，或被其他的用户进程格式化后使用。
2.2 暂留：
一旦事件被捕获，将被放置到暂留区域中。这个区域是提供了一个队列服务，用来存储和管理捕获到的事件。其提供一个影藏的安全区域，用来审计和追踪LCR中的数据。
使用者检查暂留区域的内容,并确定是否有他们所需求的事件。一个使用者可以是自定义的引用进程、其他的暂留区域（通常在一个不同的系统上）、默认的应用程序(askmac.cn)。
传递：
如果使用者是另一个暂留区，在合适的时候，这些事件被传递到另外的暂留区中，无论是相同的数据库或者远程数据库。为了简化网络拓扑和减少带宽消耗，事件不需要发送到所有的数据库和应用上。当然啦，它们可以直接通过1个或多个系统上的暂留区来到达目标系统。例如，一个事件可能通过一个中心数据库传递，但是这个数据库并不应用此事件。一个单独的暂留区域可以存储多个数据库上的事件，从而简化安装和配置。
2.3 应用：
暂留区域的事件被应用引擎所使用，在那些变化的地方，被数据库或其他的应用程序应用。oracle 流有一个灵活的应用引擎，运行用户使用标准的或者自定义的功能。它允许在必要的时候进行数据转换。提供一个明确的队列给应用开发人员使用，来让oracle stream 知道应用上的变化数据，而且也可以利用上Oracle Streams的变化捕获和传递的特性。
默认的应用
默认的应用引擎，以DML和DDL变化的形式，来应用那些显式或隐式捕获到的LCRs。
默认的应用引擎会自动检测冲突，例如目标端行记录已经发生了改变，行记录里面没有预期的值。如果检测到了冲突，那么有一些常规的解决方案可以调用。
用户自定义的应用函数：
应用引擎可以将LCRS或者用户消息 发到一个用户自定义的函数上。这样在处理事件的时候就更为的灵活了。
一个典型应用中的自定义函数，可以在应用到本地表之前，以LCR的形式来重新格式化数据。例如：字段格式、对象名、字段名的映射转换，或者用来更新那些 源数据库中可能不存在的对象。
显示的队列：
用户应用可以显示的从暂留区域中声明一个 LCRs或者用户消息的队列。这个队列运行用户可以高效的访问 stream中暂留区的数据。streams 可以将消息发送给那些注册过的PL/SQL 或OCI函数，此时应用程序多出一个轮询新消息的选择。当然应用程序可以轮询或者等待目标消息在暂留区中变的可用。
2.4规则：
streams 运行用户使用特定的规则，来控制信息的共享和发送。在最高的级别上，用户可以显示的在表，方案或者全局（数据库）层面定义哪些变化需要捕获、传递和应用。
在更复杂的需求中，例如：在给定的位置应用特定的数据子集，用户可以定义一个规则就类似在sql查询中的where条件一样。在必要的时候，规则可以存放到一起形成一个规则集合。
2.5 转换：
转换是一种对象形式在抓取和应用中的变化，或者持有数据的改变。
转换可以包含表中特定位置字段的数据类型的变化，在一个指定的位置增加一个表的字段，或者在一个特别的位置包含一个表的数据子集。
一个转换可以在入队之前被指定，用来在插入到暂留区之前，将消息转化成正确的类型。它也可以在传递的时候指定，在发送到远端地点之前用来构造数据子集。最后，它也可以在出队或者本地应用的时候被指定，
用适当地方式，格式化消息到指定位置。
2.6 管理性：
有几个工具可以用于配置、管理和监控一个流环境。主要的接口是一些 oracle 提供的 PL/SQL包。
为了帮助用户配置、管理和监控他们的流环境，oracle 在 Grid Control 中 提供了 流工具。用户可以用工具来生成，那些修改和配置流环境的脚本。此外，stream的数据字典视图也给用户提供了一些关于他们stream环境的信息。
Oracle Streams Commander (OSC) 也提供了一些关于特定流的指标。
3 准备
3.1
软件版本：
10gR2 推荐的Pacth 是10.2.0.3 (5337014) 可以参考Metalink 437838.1 来进行打 stream 的patch。自行确认补丁patch 是否被安装
10.2.0.3 上的补丁建议：
| Bug Number | Description | Comment |
| 6081550 | 一个 10.2.0.3 Data Guard Logminer/Logical Standby 的跟踪bug | 包含修复stream 捕获的bug |
| 6081547 | 一个 10.2.0.3 Data Guard Physical Standby 的跟踪bug | 包含bug5399901（归档日志可以会长时间搜索控制文件） |
| 6267873 | MLR关于Logmnr的bugs 6017440, 6067600,6064864 | 首先安装 6081550，然后移除6067600 再应用6267873 |
| 6043052 | 库缓存泄露导致的ORA-4031的bug | |
| 6375952 | MLR关于Logmnr的bugs 6067611和 6163622 | 假设6081550 已经安装，移除MLR patch 6067611 然后应用6375952.6375952包含了 |
| 5093060 | stream的bug：5000LCR的限制，在应用端引发多余的溢出控制 |
3.2 数据库参数：
以下参数是从10g 中抽出的一部分，stream最佳的实践文档可以在Metalink上找到。在配合了stream的数据库上确认参数是合适的。
设置SGA的自动管理，将SGA_TARGET设置为非0值。设置streams_pool_size=200M这样最小的流池为200m，而且会自动的根据工作负载来调整。
| 参数和建议 | 默认值 | 描述 |
| _job_queue_interval=1 | 默认：5 | 工作队列的扫描时间间隔(秒) |
| aq_tm_processes | 未设置 | 这个参数应该从init.ora移除，因为其是自动调整的。如果要设置，可以设置为1 |
| COMPATIBLE = 10.2.0 | 默认：10.0.0范围：9.2.0-当前版本
不要修改 |
这个参数指定了数据库服务必须保持的兼容性。这样在不同兼容级别可以进行交互。在10g R1 中使用流技术，这个参数必须设置为10.1.0 或者更高。如果是10 R2 这个参数必须设置为 10.2.0或者更高
|
| GLOBAL_NAMES =true | 默认:false范围：ture 或者false
可修改 |
在使用DB link的时候是否需要设置名称和数据库名称一致。在是用stream在数据库之间共享信息的时候，所有参与到流环境的数据库的这个参数设置为true |
| JOB_QUEUE_PROCESSES=4 | 默认：0范围：0-1000
可修改 |
为每个实例指定 job进程的队列数（j000-j999）。job队列进程句柄由DBMS_JOB创建。在流环境的库中这个参数最小设置为2，表示同一时刻job能同时运行的数目为2 |
| LOG_ARCHIVE_DEST_n | 默认：无范围：无
可修改 |
定义最多10个的归档地址，n可以是1-10.如果这个数据库是源端并且有捕获进程，那么一个指定的归档地址必须被指定。
如果本地的捕获进程启用，则需要指定一个本地的路径去存储归档日志。 在下游的流使用捕获 ，要将日志文件通过日志传输服务传递到下游数据库中应用，最少有一个归档路径必须制定到有捕获进程的下游数据库中。 参考 Oracle Data Guard Concepts和Administration |
| LOG_ARCHIVE_DEST_STATE_n | 默认：enable范围：alternate,reset,defer,enable
可修改 |
为响应的归档路径指定状态和LOG_ARCHIVE_DEST_n对应。确保在有捕获进程的下游数据库的归档路径状态是 enable |
| OPEN_LINKS | 默认：4范围0-255
不要修改 |
指定在一个会话中并发连接远程数据库的最大数目。这些并发的连接包含DB link 和那些使用单独进程的外部存储过程、暗盒。
在stream中确保这个参数在4以上。 |
| PARALLEL_MAX_SERVERS | 默认值来自一下参数：CPU_COUNT
PARALLEL_ADAPTIVE _MULTI_USER PARALLEL_AUTOMAT IC_TUNING 范围：0-3599 可以修改 |
指定实例在执行和恢复过程中的最大并发数。如果需要增加，oracle实例将在启动的时候从这里面的数值来增加进程。
在流环境中，每个捕获和应用进程可能使用并发服务。设置这个参数为合适的值来满足并发服务的需要。 |
| PROCESSES | 默认值：来源于PARALLEL_MAX_SERVERS
范围 6-操作系统上限 不要修改 |
指定操作系统用户可以同时连接到oracle的最大数。确保这个值能够运行所有的后天进程，比如：锁，job队列进程，并发服务进程。在流环境中，捕获和应用进程是使用的后台进程，传递任务是用的job队列进程。 |
| REMOTE_ARCHIVE_ENABLE | 默认：true范围：true 或false
不要修改 |
是否允许归档发送到远程目标端和接收远程发来的归档。在源端和下游使用了抓取服务的数据库上，这个参数都要设置为true |
| SESSIONS | 默认: (1.1 * PROCESSES) + 5范围：1-231
不要修改 |
指定在系统中能被创建的最大的会话数。在流环境中要保证这个参数的值够用，一个后台进程需要一个会话。 |
| SGA_MAX_SIZE | 默认：在启动的时候初始化SGA
范围：0-操作系统限制 不要修改 |
指定数据库实例生存周期内的SGA最大值。一个数据库存在多个抓取进程，这个值需要大一些。 |
| SGA_TARGET >0 | 默认：0（自动SGA管理关闭）范围：64-操作系统依赖
可以修改 |
指定SGA组件的总大小。如果这个参数设为非0值，那么流池将被ASMM管理。 |
| SHARED_POOL_SIZE=0 | 默认：32位–32MB，64位-84MB范围：最小的粒度-操作系统限制
可修改 |
定义shared_poold的大小。其中包含了 共享游标，存储过程，控制类结构和其他结构。如果SGA_TARGET和STREAM_POOL_SIZE设置为0，那么将从buffer cache
中获取此参数的10%来作为流池的大小。 |
| STREAMS_POOL_SIZE >200M | 默认：0范围 0-操作系统依赖 | 指定流池的大小。流池包含缓冲队列消息.流池还用于并发捕获、应用时的内部通信。如果SGA_TARGET初始化参数设置为非0的值，那么流池的大小将被ASSM指定、STREAMS_POOL_SIZE指定一个最小的值
这个参数是和可变的值，如果这个值在数据库运行的时候减小到0，此时流进程和其job将无法运行。 你可以按下列因素来增加流池的大小： 每个并行的捕获进程10MB 每个消息队列缓冲区10MB或者更大。LCRS就存放在消息队列缓冲区中。 每个并行的应用进程1MB。 你可以参考v$streams_poll_advice 来给这个参数一个合适的值。 例如：假设捕获进程并行度设置为3，那么流池要增加30MB。假设应用进程并行度是5，那么流池要增加5MB。
|
| TIMED_STATISTICS = FALSE | 默认：如果STATISTICS_LEVEL设置为TYPICAL或者ALL则为true，否则为fasle。
STATISTICS_LEVEL默认值是TYPICAL 范围：true 或false 可修改 |
指定是否进行与时间的相关统计信息收集。如果设置为true ,就在流池的动态视图中收集运行时间的统计信息。那些包含运行时间信息的视图：
V$STREAMS_CAPTURE, V$STREAMS_APPLY_COORDINATOR, V$STREAMS_APPLY_READER, V$STREAMS_APPLY_SERVER |
| UNDO_RETENTION | 默认：900（s）范围：0-232-1 （32位的最大值）
可修改 |
指定以秒为单位的撤销信息保留在数据库中的时间。
如果数据库运行1个或多个捕获进程，确保这个保留时间要足够长。如果你不确定的话，最少设置这个值为3600.如果出现ORA-1555快照太旧的错误，可以增加这个参数，指导错误消失。确保undo表空间足够大来适应此参数的设置。 |
3.3 网络连通性：
当使用WAN来传递流时，增加SDU（session data unit）来提高传输的性能。可以在sqlnet.ora中设置（参考：
Database Net Services Administrator’s Guide，http://docs.oracle.com/cd/B19306_01/network.102/b14212/performance.htm）
10g中最大值是32K。在网络传输中的SDU值由发送和接收端的连接来决定：最小的SDU值作用于2个端点间的任何单独的联系。为了提高stream在传递过程中的效率，接收端的sqlnet.ora必须包含default_sdu_size的参数。在发送端的tnsnames.ora中特定的连接服务中也要包含SDU的定义。
调整 TCP/IP 网络参数可以显著的提高WAN 中的性能。这个参数可能稍微有些不同，是依赖于操作系统的。在linux中可以如下设置到/etc/sysctl.conf中 sysctl -p 启用：
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
增加 TCP自动缓冲限制#最小，默认，最大字节数：
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
此外SEND_BUF_SIZE和RECV_BUF_SIZE 在sqlnet.ora中增大配置也能提高系统性能。
这些参数的大小就是发送和接收传递消息时使用的缓冲大小。这些参数最好在精细地分析系统影响后，再进行增加。
更多详细详细，可以回顾Oracle Net Services Guide
3.4权限：
为了创建捕获和应用进程，stream的管理者必须拥有DBA权限。这个权限必需在源端数据库和目标端数据库，显式的进行赋权：
grant dba to strmadmin;
此外，一些其他的权限需要通过GRANT_ADMIN_PRIVILEGE 过程来赋予。所有使用stream的数据库中stream管理员的方案（strmadmin）都要进行：
BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(‘STRMADMIN’);
END;
/
3.5 源端的配置：
下面建议适用于源端数据库，即那些有捕获进程的数据库。
3.5.1 强制日志模式
以效率为目的使用的nologging选项，可能加快一些数据库的数位。但是在流保护下的环境不适用。
从oracle 9.2开始，oracle 提供了一个参数来防止这些情况发生。这就是 forced logging。
在主库上用下列命令开启forced logging：
alter database force logging;
如果明确的知道在数据库层面开启forced logging，会导致太多的日志开销。你可以在其他粒度上开启force logging，如在表空间级别。
这个只指定具体应用的表空间，而并非影响全局：
alter tablespace <tablespace_name> force logging;
3.5.2 追加日志
在每个源端确认有附加日志。在 10R2中，在数据库对象准备被流进程捕获时，附加日志被自动配置在那些有主键、唯一约束、或外键定义上。
DBMS_STREAMS_ADM这个过程自动为本地捕获进程进行对象准备，用来维护streams和增加一些规则。
在下游捕获端（即那些有用捕获进程配置的其他数据库），这个远端日志产生的数据库必须为下游的捕获进程所需要的对象开启附加日志。
在oracle 10G R1 中，你必须开启附加日志，记录额外的数据到日志中来完成一些特定任务，例如解决冲突。至少，那些拥有主键的被复制的对象在流环境中需要开启附加日志。可以通过设置表上特定的列来附加，这提供了一种简单的设定键的方式。
附加日志会被自动开启，当源端表准备捕获的时候：
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION
任何列中在转换中指定了规则或使用了DML操作的，在源端必须记录日志。这些附加的信息必须显式的用数据库管理员以下面的sql语法来指定：
ALTER TABLE… ADD SUPPLEMENTAL LOG… .
在数据库级别验证源端是否使用了附加日志：
SELECT supplemental_log_data_pk, supplemental_log_data_ui
FROM V$DATABASE;
在表级别验证：
SELECT supplemental_log_data_pk
, supplemental_log_data_ui
, supplemental_log_data_fk
FROM dba_capture_prepared_tables
UNION
SELECT supplemental_log_data_pk
, supplemental_log_data_ui
, supplemental_log_data_fk
FROM dba_capture_prepared_schemas
UNION
SELECT supplemental-log_data_pk
, supplemental_log_data_ui
, supplemental_log_data_fk
FROM dba_capture_prepared_database;
检查附加日志组：
SELECT log_group_name
, table_name
, decode(always, ‘ALWAYS’, ‘Unconditional’
, NULL , ‘Conditional’) ALWAYS
FROM DBA_LOG_GROUPS
检查在 附加日志组中的字段：
SELECT log_group_name
, column_name
, position
FROM dba_log_group_columns
WHERE table_name = ‘<table_name>’
AND owner=‘<owner>’;
3.5.3 归档必须被开启
源端和那些下游使用抓取进程的前段数据库都必须启用归档。
# Check Parameter log_archive_dest_<n>
# Check Parameter log_archive_dest_state_<n>
# Check Parameter log_archive_format
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
# Check Archiving
ARCHIVE LOG LIST
3.5.4 数据库链接
流通过私有的DB link 经过标准的TNS别名连接到远程数据库。这个链接属于STRMADMIN，并且远程的用户名和密码也都是STRMADMIN的。这个STRMADMIN的密码在所有地方都是一样的。流不需要公共的DB link
CREATE DATABASE LINK <dblink>
CONNECT TO STRMADMIN identified by <PWD>
USING <TNS_qualifier>;
验证下列参数被正确的设置：
GLOBAL_NAME=true，TNS服务配置在TNSNAMES.ora中
验证dblink 的有效性：
SELECT global_name FROM global_name@<dblink>;
SELECT username FROM user_users@<dblink>;
3.5.5 实现心跳表
确保 DBA_CAPTURE中的 applied_scn 定期的更新，来实现一个心跳表。
心跳表适用于活动率很低的数据库。流的捕获进程会在每10MB的日志生产之后请求一个检查点。在检查点的过程中，stream会进行元数据的更新维护，如果里面有活动的事物。实现一个心跳表可以确保那些事物经常的发生，从而给源数据库带来更频繁的元数据更机会。
此外，心跳表给管理员提供了一个快速的反馈，来确定流复制的健康性。
实现心跳表：
在源端创建一个带有时间字段和global_name的字段的表。增加一条规则来捕获这个表的变化，并传递到所有目标端。同时确保每个目标端都会应用这个变化。在源端建立一个job来周期的更新这张表，例如每分钟更新一次。
3.5.6 队列配置
strmadmin 用户需要有自己的表空间，所有的流队列将存放到这个表空间中。
这个表空间将用户创建所有流管理的对象，包括任何溢出的内存消息队列。
CREATE TABLESPACE <tablespace_name>
DATAFILE <datafile_name>’ SIZE 25 M REUSE
AUTOEXTEND ON MAXSIZE UNLIMITED;
create USER strmadmin identified by strmadmin DEFAULT TABLESPACE <tablespace_name>
QUOTA UNLIMITED ON <tablespace_name>;
确保配置队列分离，将本地抓取的队列和远端接收到的队列分开。这是特别重要的，特别是在多个库中配置双向复制的时候。队列名不能超过24字节。队列表名不能超过18字节
流队列可以通过STRMADMIN 用户使用DBMS_STREAMS_ADM.SET_UP_QUEUE 创建，可选参数如下：
queue_table => ‘strmadmin.<QUEUE_NAME>’
queue_name => ‘strmadmin.<QUEUE_NAME>’
queue_user => ‘STRMADMIN’
3.5.7 流粒度
表、方案、全局级别的复制
对于流来说，可以在指定的表，方案和全局数据库层面工作。
通过DBMS_STREAMS_ADM来定义 捕获，应用和传播：
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES
DDL和DML选项
在每个DBMS_STREAMS_ADM.ADD_[TABLE|SCHEMA|GLOBAL]_RULES中可以指明是否是DML和DDL的选择，只需增加下列参数：
include_dml => TRUE
include_ddl => TRUE
标签：
可以在日志中加入标签，默认这个标签是00.流可以根据这个元素来捕获、传递和应用。
include_tagged_lcr => FALSE
默认值是 false，防止应用消息重复的抓取。
可以在下列包中定义：DBMS_STREAMS_ADM，DBMS_CAPTURE_ADM, DBMS_PROPAGATION_ADM and
DBMS_APPLY_ADM
可以消除特定表或者对象的变化，通过一起指定include_tagged_lcr、表、对象名在一个流进程的规则中。
抓取、传递，应用进程的参数化：
尽可能的为没个捕获和应用进程选择参数。除此之外你也要对传递进行更改。
捕获和应用：
DBMS_APPLY_ADM.SET_PARAMETER (
apply_name IN VARCHAR2,
parameter IN VARCHAR2,
value IN VARCHAR2);
DBMS_CAPTURE_ADM.SET_PARAMETER (
apply_name IN VARCHAR2,
parameter IN VARCHAR2,
value IN VARCHAR2);
改变传递用DBMS_AQADM包：
DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE (
queue_name IN VARCHAR2,
destination IN VARCHAR2 DEFAULT NULL,
duration IN NUMBER DEFAULT NULL,
next_time IN VARCHAR2 DEFAULT NULL,
latency IN NUMBER DEFAULT 60,
destination_queue IN VARCHAR2 DEFAULT NULL)
下表列出了一些可能会改变的参数：
抓取进程
| 参数和建议 | 默认值 | 意见 |
| PARALLELISM=1 | 默认：1 | 在目标端应用改变的并行执行服务的数量。在配置并发参数之前确保在源端配置了附加日志。 |
| _CHECKPOINT_FREQUENCY=100 | 默认：10 | 修改logminer 检查点的频率，特别是当数据库中有大量的LOB字段和DDL的时候。一个大的值，减少 logminer 检查点的频率，小的值增加频率。默认是每隔10MB的日志产生一次logminer检查点。如果这个值设置为100，那么每100MB的日志才会产生一个logminer 检查点。建议增加这个值到数据库一小时内产生的日志量。这个参数设置到100可以减少logminer 检查点的请求，从而减少日志的产生和减少检查点的元数据。如果日志文件超过300M而且数据库中有很多活动事物，可以增大此参数。如果此参数增大，那么重启streams 捕获进程时候需要保留更长时间的归档。 |
| _SGA_SIZE | 默认：10 | 在流池中 logminer 进程占用的内存数量。默认流池分给logminer的是10MB。在有大的lob对象处理的时候需要增加这个参数。除非是遇到了ORA-1341错误，一般不用增加这个参数。流池的内存只给logminer使用，并不分配给其他使用。 |
| latency=5 | 一个消息传播后加入队列进入传播窗口中最大的等待时间，单位是秒。默认的值是60。如果在一个调用中没指定这个参数，那么将用默认值覆盖所有现存的任何值。
例如：如果这个值设置为60秒，在一个传播窗口中，如果没有消息传递，那么从队列传递到目标端，传递的时间不会超过60秒。至少60秒，队列将再次进行检查将消息传递到目标端。如果设置成600，那么队列在10分钟内可能不会进行检查，如果设置为0，那么job 队列进程将等待消息入队，直到这个消息被传递出去。 |
应用参数：
在应用进程被创建的时候 设置下列参数：
| 参数和建议 | 默认值 | 意见 |
| DISABLE_ON_ERROR=N | 默认：Y | 如果是Y，那么应用进程会在遇到第一个无法解决的错误的时候不可用，即使这个错误不是致命的。如果是N，应用进程会忽略这些无法解决的错误。 |
| PARALLELISM= 4 | 默认：1 | 并行的应用进程配置来处理源端传递过来的事物。可以选择设置为4,8,12,16，这个基于源端产生的复制负载情况和目标端的CPU个数。 |
在某些时候，设置下列隐藏参数可以提高性能。这些参数可以在主要的工作负载是update操作，并且只更新一张表上很少几个字段的时候设置：
| 参数和建议 | 默认值 | 意见 |
| _DYNAMIC_STMTS=Y | Default: N | 如果是Y，那么对于update的情况，应用进程将对sql语句进行优化基于那些需要更新的列。 |
| _HASH_TABLE_SIZE=1000000 | 设置用于计算事物依赖的哈希表大小为1000000 | |
| _TXN_BUFFER_SIZE=10 | 默认：10+并行度 | 为了防止在处理大事物的时候使用并发而产生的溢出，设置这个值为10+并行度。如果这个事物非常大（大于100000’s 并行度大于1），那么考虑减少事物缓冲大小 甚至更低的值（例如2+并行度），默认值是 80*并行度 |
–这里有点奇怪，文档中的默认值不同，再查下。
3.6 应用端的权限：
需要赋予应用用户在相关表上执行DML （INSERT/UPDATE/DELETE/SELECT）和DDL（CREATE TABLE,CREATE INDEX,CREATE PROCEDURE） 的权限:
grant create any table
, create any index
, create any procedure
, alter any table
, alter any procedure
TO STRMADMIN;
grant insert any table TO STRMADMIN;
grant update any table TO STRMADMIN;
grant delete any table TO STRMADMIN;
grant select any table TO STRMADMIN;
grant alter any table TO STRMADMIN;
3.7初始化
在使用SCN初始化应用端的之前，请确保捕获端已经初始化。可以用下面的包DBMS_CAPTURE_ADM来完成：
DBMS_CAPTURE_ADM.PREPARE_SCHEMA_INSTANTIATION(
schema_name IN VARCHAR2,
supplemental_logging IN VARCHAR2 DEFAULT ‘keys’);
初始化准备是在第一次用DBMS_STREAMS_ADM增加 规则的时候进行的。然而，当有新的节点加入到系统中时，这个操作都要再执行一次。
在目标端会产生一些初始化的对象/表，如下的调用：
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
source_object_name IN VARCHAR2,
source_database_name IN VARCHAR2,
instantiation_scn IN NUMBER,
apply_database_link IN VARCHAR2 DEFAULT NULL);
你可以在EXP/IMP 或 datapump 进行初始化的时候手动指定SCN。
如果要手动指定了方案下每个表的初始化SCN，可以在DBMS_STREAMS_ADM: 包中的SET_SCHEMA_INSTANTIATION_SCN过程中使用RECURSIVE=>TRUE选项：
DECLARE
iscn NUMBER;
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN@<target_db>
( source_schema_name => ‘<schema_name>’
, source_database_name => ‘<source_db>’
, instantiation_scn => iscn
, recursive => true
);
END;
/
COMMIT;
如果使用 数据泵，在导出的时候可以指定下列参数：
FLASH_BACK _SCN = <SCN>
在导入的时候要指定：
STREAMS_INSTANTIATION = Y
STREAMS_CONFIGURATION = N
你甚至可以在目标端初始化那些源端不存在的对象，所以你可以选择你想使用的初始化方式。
3.8：冲突解决
oracle 为流提供以下预处理冲突程序的几种方式：OVERWRITE,DISCARD,MAXMUM,MINMUM.
OVERWRITE
当冲突产生时，OVERWRITE操作将从LCR中的取源端的新值来替换目标的当前值。
DISCARD
当冲突产生时, DISCARD 操作会忽略从源端传递的LCR值，保持目标端的值。
MAXIMUM
当冲突产生时, MAXIMUM 冲突处理 会将从源端过来的LCR新的值和目标端要处理的当前值进行对比。如果要解决冲突的字段（特定的字段例如version）的值比当前值大，那么应用进程就会使用LCR。如果新的值比当前值要小，那么应用进程会用目标数据库的值解决冲突。
MINIMUM
这个处理过程正好和MAXIMUM相反，当解决字段的值比当前值要小的时候会应用LCR，比当前值大的时候会使用目标数据库的值来处理冲突。
解决冲突的配置可以通过下列过程：
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
,object_name => ‘<OWNER>.<TABLE_NAME>’
, method_name => ‘MAXIMUM’
, resolution_column => ‘VERSION’
, column_list => <COLUMN_LIST>);
4 流的安装
4.1 架构
为了说明提出下列假设：
1.只有一个中心数据库服务（HUB），和多个分散的数据库服务（SPOKES）。所有的改变都必须经过HUB，通过HUB传递到SPOKE，并且在应用和传递到其他的SPOKE（消息不复制回传到原来的spoke上）
2、HUB&SPOKE 使用多个位置的捕获进程。请注意，这个配置不是建议的典型的HUB&SPOKE的配置，但是考虑到在每个单独的SPOKE之间没有交叉关系依赖的影响。
3、HUB用户使用多个位置的多应用进程。每个位置在流环境中都是独立的应用进程。
4、SPOKE 配置也是一样的。所有的SPOKE 有一个捕获和一个应用进程构成。
| 类型 | HUB | SPOKE |
| 捕获 | 使用标签 | 不使用标签 |
| 传递 | 使用标签额外的规则 | 不是用标签 |
| 应用 | 不使用标签设置应用标签<n> | 使用标签 |
| 队列 | <n> 应用队列<n>捕获队列 | 1 应用队列1捕获进程 |
4.2 流安装
4.2.1创建一个流环境
创建流环境在下列几个步骤。基础的脚本不在文档中。这个过程的顺序如下：
1 .创建全局流环境
初始化参数
数据库或表级别 force logging
创建表空间
调整删除归档文件的备份过程
增加TNS消息
2.创建流管理员
创建 STRMADMIN 管理员
给用户赋权
创建db link
创建数据库队列
应用数据库对象上创建适当的权限
3.在表，方案上的流配置
准备应用进程
准备捕获进程
准备传递进程
初始化 对象：
在源端准备对象
初始化到目标端
1.调整 捕获，传递，应用进程的参数
2.开启进程：
捕获
应用
4.2.2 增加一个新的SPOKE 节点到流配置中
增加一个节点由同一个管理者管理。你必须区别HUB和SPOKE的配置。在HUB上，你可以不用做一些不必要的操作。指导建议如下：
1.增加TNS 信息。
2.增加 捕获和应用队列。
3.创建DB link。
4，完成3以上的步骤。
4.2.3 从流配置里移除一个SPOKE
你可以通过移除传递，来达到移除流节点的目的。在SPOKE上，可以运行存储过程DBMS_STREAMS_ADM.remove_streams_configuration
5.监控
5.1 介绍
一旦配置都创建完毕，那么必不可少的需要检查一切是否是在平稳的运作中。下面给出了一些不同的选择去监控环境。
5.2 固定视图
下面的动态视图可以用来监控流
| 流视图名 | RAC下的视图名 |
| V$STREAMS_CAPTUREV$STREAMS_APPLY_COORDINATOR
V$STREAMS_APPLY_READER V$STREAMS_APPLY_SERVER V$STREAMS_POOL_ADVICE V$STREAMS_TRANSACTION V$BUFFERED_PUBLISHERS V$BUFFERED_QUEUES V$BUFFERED_SUBSCRIBERS V$PROPAGATION_RECEIVER V$PROPAGATION_SENDER V$RULE V$RULE_SET V$RULE_SET_AGGREGATE_STATS |
GV$STREAMS_CAPTUREGV$STREAMS_APPLY_COORDINATOR
GV$STREAMS_APPLY_READER GV$STREAMS_APPLY_SERVER GV$STREAMS_POOL_ADVICE GV$STREAMS_TRANSACTION GV$BUFFERED_PUBLISHERS GV$BUFFERED_QUEUES GV$BUFFERED_SUBSCRIBERS GV$PROPAGATION_RECEIVER GV$PROPAGATION_SENDER GV$RULE GV$RULE_SET GV$RULE_SET_AGGREGATE_STATS
|
静态视图
| 捕获的视图 | 应用的视图 |
| DBA_CAPTUREDBA_CAPTURE_EXTRA_ATTRIBUTES
DBA_CAPTURE_PARAMETERS DBA_CAPTURE_PREPARED_DATABASE DBA_CAPTURE_PREPARED_SCHEMAS DBA_CAPTURE_PREPARED_TABLES |
DBA_APPLYDBA_APPLY_CONFLICT_COLUMNS
DBA_APPLY_DML_HANDLERS DBA_APPLY_ENQUEUE DBA_APPLY_ERROR DBA_APPLY_EXECUTE DBA_APPLY_INSTANTIATED_GLOBAL DBA_APPLY_INSTANTIATED_OBJECTS DBA_APPLY_INSTANTIATED_SCHEMAS DBA_APPLY_KEY_COLUMNS DBA_APPLY_OBJECT_DEPENDENCIES DBA_APPLY_PARAMETERS DBA_APPLY_PROGRESS DBA_APPLY_SPILL_TXN DBA_APPLY_TABLE_COLUMNS DBA_APPLY_VALUE_DEPENDENCIES |
| 传递和队列的视图 | 流视图 |
| DBA_PROPAGATIONDBA_QUEUE_SCHEDULES
DBA_QUEUE_SUBSCRIBERS DBA_QUEUE_TABLES DBA_QUEUES |
DBA_REGISTERED_ARCHIVED_LOGDBA_RECOVERABLE_SCRIPT
DBA_RECOVERABLE_SCRIPT_BLOCKS DBA_RECOVERABLE_SCRIPT_ERRORS DBA_RECOVERABLE_SCRIPT_PARAMS DBA_STREAMS_ADD_COLUMN DBA_STREAMS_ADMINISTRATOR DBA_STREAMS_DELETE_COLUMN DBA_STREAMS_GLOBAL_RULES DBA_STREAMS_MESSAGE_CONSUME DBA_STREAMS_MESSAGE_RULES DBA_STREAMS_NEWLY_SUPPORTED DBA_STREAMS_RENAME_COLUMN DBA_STREAMS_RENAME_SCHEMA DBA_STREAMS_RENAME_TABLE DBA_STREAMS_RULES DBA_STREAMS_SCHEMA_RULES DBA_STREAMS_TABLE_RULES DBA_STREAMS_TRANSFORM_FUNCTI DBA_STREAMS_TRANSFORMATIONS DBA_STREAMS_UNSUPPORTED DBA_RULE_SET_RULES DBA_RULE_SETS DBA_RULES DBA_HIST_BUFFERED_QUEUES DBA_HIST_BUFFERED_SUBSCRIBERS DBA_HIST_RULE_SET DBA_HIST_STREAMS_APPLY_SUM DBA_HIST_STREAMS_CAPTURE DBA_HIST_STREAMS_POOL_ADVICE |
5.3 监控工具 STRMMON
STRMMON是一个集中监控流的工具。通过这个工具，数据库管理员可以快速的获得当前流活动的一个概况。在每一行都会显示报告消息。报告星星的数目和迭代显示都是可以配置的 STRMMON可以在$ORACLE_HOME下rdbms/demo中直接使用
5.4 alert 日志
流将长运行和长事物的报告打印在alert.log中。
长时间运行的事物是那种在较长的时间内（例如20分），没有事物活动（即，没有新的改变，提交和回滚）。大的事物会有大量的变化记录。长事物的情况将每20分钟在alert.log中打印一次。并不是所有的此类事物都打印，只是20分钟一次。当提交和回滚操作出现时，这些消息也将在alert.log中打印。
5.5 流健康检查脚本
这个健康检查脚本查询一些消息来确定流环境的配置。这个脚本应该在每个参与流环境的数据库上执行。出了配置信息，还可以对指定的规则和一些其他问题进行诊断。这个脚本是一个很好用的工具来解决客户的问题。脚本可以参考Note: 273674.1
6 管理：
6.1 启动和停止流环境
开启流环境
在目标端启动应用进程，操作如下：
begin
dbms_apply_adm.start_apply(<APPLY_NAME>);
end;
/
在目标端开启传递和捕获进程：
begin
dbms_propagation_adm.start_propagation(<PROPAGATION_NAME>);
end;
/
begin
dbms_capture_adm.start_capture(<CAPTURE_NAME>);
end;
关闭流环境
目标端关闭
关闭捕获和传递进程
begin
dbms_capture_adm.stop_capture(<CAPTURE_NAME>);
end;
/
begin
dbms_propagation_adm.stop_propagation(<PROPAGATION_NAME>);
end;
/
关闭应用进程
begin
dbms_apply_adm.stop_apply(<APPLY_NAME>);
end;
/
6.2使用grid control 监控流进程
基于网络来进行故障排查.DBA需要用过监控检查每个节点上的经常。例如确定传递和捕获进程是正常的。使用监控脚本去验证这些。
database control是 企业管理器网络的一套应用，用来管理oracle10g. database control 随着数据库的安装而可用。通过database control 你可以管理单实例或者一个数据库集群。
页面上的选择是用过 Maintenance tab -> Streams section ->Management link
下面列出了一些个人测试场景更多的细节
6.2.1
使用 grid control 来检查捕获进程的状态
捕获进程的状态如何？是否异常中断？
这里有一个存储过程streams_package .status_streams在数据库层面返回了所有相关进行的基本状态消息，或者使用下列查询：
SELECT apply_name
, source_commit_scn
, message_number
, source_database
, local_transaction_id
, error_number
, error_message
, message_count
FROM dba_apply_error
ORDER BY source_commit_scn;
6.2.2 检查传递进程的状态
6.2.4 检查db link的状态
你可以使用select * from dual@’db_link_name’，来检查DB link 是否有效。DB link将在密码变化后失效，需要重建。
如果是实例down 导致的失效，你需要重新启动传递进程来清除错误：
DBMS_PROPAGATION_ADM.stop_propagation(‘name_of_propagation’,for
ce=>true);
DBMS_PROPAGATION_ADM.start_propagation(‘name_of_propagation’);
6.2.5 执行定期的维护。
确认检查点的周期
检查点进程会周期性的重启。这些检查点默认被 sysaux表空间持有。抓取参数 checkpoint_retention_time,控制了检查点保留的时间，来移动FIRST_SCN前进。
FIRST_SCN是最低的可以看到捕获变化的SCN。当超过checkpoint_retention_time的时间，FIRST_SCN 被移除，流元数据表的前一个值可以被清理，在sysaux中的空间可以重用。
改变这个参数可以使用DBMS_CAPTURE_ADM.ALTER_CAPTURE
在日志中刷新数据字典信息。通过DBMS_CAPTURE_ADM.BUILD将数据字典信息转储到日志里面。这样在创建捕获经常和经常重建的时候会减少日志的开销。
为初始化准备数据库对象。通过DBMS_CAPTURE_ADM.PREPARE_*_INSTANTIATION *是表示抓取的数据库对象的级别（TABLE, SCHEMA, GLOBAL)，可以用来重建或新建一个抓取进程。
每周进行logminer 数据字典的重建，和安照开发维护指南来进行方案的初始化。
6.2.6 当丢失归档的时候 捕获进程可能出现的问题。
找到捕获进程最后需要的归档时非常重要的。因为这个归档在重启进程的时候需要用到。如果表现的错误不是捕获进程错误，那么一个潜在的解决方案是重启创建捕获进程。
下面的脚本可以重置SCN和包含这些SCN的归档。
重置捕获进程需要最小的一个归档日志在确定所需的 检查点SCN，下面的脚本可能运行：
set serveroutput on
DECLARE
hScn number := 0;
lScn number := 0;
sScn number;
ascn number;
alog varchar2(1000);
BEGIN
select min(start_scn), min(applied_scn) into sScn, ascn
from dba_capture;
DBMS_OUTPUT.ENABLE(2000);
for cr in (select distinct(a.ckpt_scn)
from system.logmnr_restart_ckpt$ a
where a.ckpt_scn <= ascn and a.valid = 1
and exists (select * from system.logmnr_log$ l
where a.ckpt_scn between l.first_change# and
l.next_change#)
order by a.ckpt_scn desc)
loop
if (hScn = 0) then
hScn := cr.ckpt_scn;
else
lScn := cr.ckpt_scn;
exit;
end if;
end loop;
if lScn = 0 then
lScn := sScn;
end if;
dbms_output.put_line(‘Capture will restart from SCN ‘ || lScn ||’ in
the following file:’);
for cr in (select name, first_time
from DBA_REGISTERED_ARCHIVED_LOG
where lScn between first_scn and next_scn order by
thread#)
loop
dbms_output.put_line(cr.name||’ (‘||cr.first_time||’)’);
end loop;
END;
/
6.2.7 RMAN和删除归档
在RMAN中配置删除策略
这个策略不是流的策略，但是在某些情况会影响。例如如果设置‘CONFIGURE ARCHIVELOG DELETION POLICY TO NONE’。在闪回区空间压力下，那些没有被捕获进程处理的日志会被删除。
在 进行RMAN备份 的时候使用 DELETE [ALL] input 选项：
. 这个命令会在备份成功的时候删除 输入的归档。这个选项不会删除那些没有被传递到备份端（流目标端）的归档。但是那些已经传递过去的即使没有被应用，还是会被删除。
. 在数据库开启的时候，这个命令不会删除捕获进程需要的归档。但是在数据库mount或者关闭的时候，这个选项不能决定哪些归档是捕获进程所需要的，因此都会被删除。
. 在10.2.0.3版本以上，不会删除那些保证安全还原点所需要的归档。
使用RMAN命令删除：
DELETE ARCHIVELOG
这个命令不会遵循任何 DG或者stream 的保护。一旦命令执行成功，那些DG 或者stream所需要的归档可能会被删除。
DELETE OBSOLETE
在数据库开启的时候，这个命令不会删除捕获进程需要的归档。但是在数据库mount或者关闭的时候，这个选项不能决定哪些归档是捕获进程所需要的，因此都会被删除。
7 故障解决
解决丢失 流数据字典的可以参考：Note.212044.1
10.2减少LOGMNR_RESTART_CKPT$ 高水位的可以参考Note.429599.1
应用进程故障解决可以参考 Note 230898.1
7.1 C001：大的TXN 或者流中有大事务
可以在告警日志中看到下列信息：
C001: large txn detected (341224 LCRs), xid: 0x001e.009.000c43d8
可以用具体的包来查询信息dbms_logmnr.<procedure_name>()，具体参考metalink Note 291686.1 LogMiner Utility Release 8.1.x – 10g
一般情况下，应用进程将在超过10,000个LRCS下溢出。txn_lcr_spill_threshold这个参数控制了这个数值。你可以基于事务的大小来调整参数：
exec dbms_apply_adm.set_parameter(‘app_name’,’ txn_lcr_spill_threshold
‘,'<number>’)
下面查询语句可以显示每个应用进程的信息：
COLUMN APPLY_NAME HEADING ‘Apply Name’ FORMAT A20
COLUMN ‘Transaction ID’ HEADING ‘Transaction ID’ FORMAT A15
COLUMN FIRST_SCN HEADING ‘First SCN’ FORMAT 99999999
COLUMN MESSAGE_COUNT HEADING ‘Message Count’ FORMAT 99999999
SELECT APPLY_NAME,
XIDUSN ||’.’||
XIDSLT ||’.’||
XIDSQN “Transaction ID”,
FIRST_SCN,
MESSAGE_COUNT
FROM DBA_APPLY_SPILL_TXN;
可以参考Note 230898.1
溢出的消息是溢出延期的状态、这些消息没被应用。这些遗留下的消息可能会成为孤儿事务。
你可以使用下面的语句查询：
select * from dba_apply_progress;
如果没有孤立的TXN，会有变化。如果这里的信息不是最新的，那么可能有孤立的事务错过了提交或者回滚。你可以指定dbms_aqadm.purge_queue_table 来清理这些记录。
为了提高溢出表的性能，在后续的操作中，你可以做下列操作：
alter table aq$_<queue_table_name>_p enable row_movement;
alter table aq$_<queue_table_name>_p shrink space;
alter table aq$_<queue_table_name>_p disable row_movement;
7.2 移动 FIRST_SCN
在10g中，可以通过捕获进程使用DBMS_CAPTURE_ADM.ALTER_CAPTURE移动first_scn .来释放system.logmnr_restart_ckpt$中的空间。在10.1.0.5以上的版本FIRST_SCN移动之后不用重启捕获进程。
确定当期SCN和重置捕获进程上的SCN：
BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE
( capture_name => ‘<Streams_Capture>’
, first_scn => <first_scn>
);
END;
/
减少LOGMNR_RESTART_CKPT$的空间
alter table system.LOGMNR_RESTART_CKPT$ enable row movement;
alter table system.LOGMNR_RESTART_CKPT$ shrink space ;
alter table system.LOGMNR_RESTART_CKPT$ disable row movement;
7.3:
在V$STREAMS_CAPTURE中的初始化字典状态
当一个捕获进程（不是新创建的进程），不启动进程找不到要读取的日志文件，报出‘字典初始化’时，可以用下面步骤来确定所需要的日志：
alter system set events ‘1349 trace name context forever, level 7’;
检查导出的dump 文件中包含Low ckpt scn: 的信息
将16进程的SCN转换成十进制的SCN。
用这个SCN在v$archived_log视图中找到 被first_change# 和next_change# 包含此SCN的归档日志。
或者用DBA_REGISTERED_ARCHIVED_LOG中的first_scn和next_scn来确定。
从备份中恢复这个缺失日志，一直到所有可以使用的文件，保证中间不会有空白。
7.4 丢失流多版本数据字典
这个错误发生在当 数据库中指定的对象不可用的时候。此消息会在 P000的应用进程端生成跟着文件。当这个错误发生的时候 LCR不会被应用。即使多版本数据字典信息不可用，但是应用进程不会中断或不可用。
后台：
当一个捕获进程创建的时候，一个重复的流数据字典会被自动的生成。这个数据字典有多个版本的副本来保存信息，在源端的数据库的主数据字典中。当捕获进程评估规则和创建LCRS的时候，流数据字典用来管理对象名称，对象版本信息，内部表示源表表明的数值，列名和列数据类型。这个映射让每个捕获事件尽可能的小，因为每个事件可以用数值来存储而不是用名称。每当有数据库结构变化的DDL产生时，这些信息都是自动维护的。
oracle 通过流传播自动维护每个节点中的 多版本流数据字典。oracle 从源端的数据字典发送内部消息去通知所有的数据库的传递 job 把那些需要从源端接受基于规则的捕获信息，发送到目标端。
当流数据字典版本信息传递到目标队列时，它会立马合并到当前数据库的流数据字典中，并在队列中移除此信息。
原因：
这个错误会在下面2个场景发生：
1）在跟踪文件中的对象号在源端没有被配置。
2）在目标端使用dbms_logminer_d.set_tablespace过程重置流数据字典表空间的时候发生数据字典表的丢失。在默认情况下，这些表存放在SYSTEM表空间中。为了避免这个问题，建议dbms_logminer_d.set_tablespace过程最好是在 所有节点完成流配置之前运行。
修复：
1）把特定的对象填入数据字典中。
a.确定哪些对象丢失。跟着文件中包含了确定丢失对象的信息。
gdbnm 在源端表示一个全局的丢失对象的名称。
objn 是源端的 对象号。根据这个数值通过DBA_OBJECTS可以查到对应的名称。
objx 是源端对象的版本号
scn 是出现丢失事物的SCN号。
b.在源端，重新注入对象信息到数据字典表中，使用不同的粒度如下：
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION
DBMS_CAPTURE_ADM.PREPARE_SCHEMA_INSTANTIATION
DBMS_CAPTURE_ADM.PREPARE_GLOBAL_INSTANTIATION
c.确保源端可以传送到目标端，这样字段信息就可以重载到目标端。
2）检查流数据字典表的信息：
a.SYSTEM.LOGMNRC_DBNAME_UID_MAP
这个表关联了源端数据库全局名称和一些其他方案数据字典表的索引。
- SYSTEM.LOGMNRC_GTLO
这个表列出了所有源点数据字典中的对象。下面的查询可以显示数据字典信息，在特定的地方：
select global_name,ownername,lvl0name,baseobj# from logmnrc_gtlo o ,
logmnrc_dbname_uid_map m where m.logmnr_uid=o.logmnr_uid order by 1,2,3;
global_name 是源端全局的名称
owner name 是源端方案的拥有者
lvl0name 是源端对象名
baseobj# 是源端基础对象数值
c.如果表示空的，没有数据，那么用步骤1来重新生成数据。
例子：
添加一个特定的对象当数据字典表中：
- 确定丢失的对象.
*** 2007-06-06 09:28:10.445
knllgobjinfo: MISSING Streams multi-version data dictionary!!!
knlldmm: gdbnm=BMPR
knlldmm: objn=2956682
knlldmm: objv=1
knlldmm: scn=6944984413724
select * from dba_objects@BMPR where object_id = 2956682
OWNER PSBMPR11
OBJECT_NAME TEST_BUG
SUBOBJECT_NAME
OBJECT_ID 2956682
DATA_OBJECT_ID 2956682
OBJECT_TYPE TABLE
CREATED 06/06/2007 8:36:32 AM
LAST_DDL_TIME 06/06/2007 8:37:21 AM
TIMESTAMP 2007-06-06:08:36:32
STATUS VALID
TEMPORARY N
GENERATED N
SECONDARY N
b.在源端执行：
BEGIN
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(table_name
=> ‘PSBMPR11.TEST_BUG’);
END;
c.确保传递进程是正常的。所有传播进程的问题都已经解决。
2)检查数据字典表的数据
select global_name, ownername, lvl0name, baseobj#
from system.logmnrc_gtlo o, system.logmnrc_dbname_uid_map m
where m.logmnr_uid = o.logmnr_uid
order by 1, 2, 3;
GLOBAL_NAME BMPR
OWNERNAME PSBMPR11
LVL0NAME TEST_ BUG
BASEOBJ# 2956682
4) DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@<destination
site> (
source_schema_name => ‘<schema>’,
source_database_name => ‘source_db’,
instantiation_scn => iscn
5)确保附加日志已经使用：
数据库重启不需要重新配置，在创建捕获进程间确保运行了下面语句：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER SYSTEM SWITCH LOG
8 附加信息
8.1 清除或卸载 流配置
要完全移除流配置，可以使用DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION api,然后再删除stream 管理员的方案 DROP USER … CASCADE
确保在此之前所有的进程都停止了。
REMOVE_STREAMS_CONFIGURATION
移除stream 可以使用DBMS_STREAMS_ADM.REMOVE_QUEUE
在规则会在进程删除中自动删除，或者在命令中指定drop_unused_rule_sets参数。
dbms_streams_adm.drop_unused_rule_sets
Comment