捕获阶段：应该想到的是：捕获进程的状态，数据库的参数设置，关于RULE的设置，错误信息的提示。
解决方案：检查捕获进程的状态：
SELECT capture_name, status_change_time, error_number, error_message
FROM DBA_CAPTURE;
正确的状态应该是enabled。可能的状态：enabled, disabled, or aborted
如果状态是disabled,试着重新启动捕获进程.
如果状态是aborted,说明你的流配置遇到了一个问题，你可以是需要查看一下警告日志或跟踪文件，
另外捕获进程的状态是enabled，但也不能捕获事务的变化，其原因是捕获进程有时会滞后于事务的变化。
使用下面的语句查看是否发生捕获进程滞后于事务变化的情况。
SELECT CAPTURE_NAME,
((SYSDATE - CAPTURE_MESSAGE_CREATE_TIME)*86400) "Redo scanning latency", CAPTURE_MESSAGE_CREATE_TIME
FROM V$STREAMS_CAPTURE;
通过"Redo scanning latency" 列，我们可以判断捕获进程是否是滞后于事务变化。
对于上游捕获进程，最新的事务就是最新归档重做日志入口最后一个事务。
对于下游捕获进程，最新的事务是已经加到LogMiner会话中的那个归档重做日志入口里最新的SCN所对就的那个事务。
使用下面的查询来查看捕获进程捕获到的最新的事务信息。
SELECT v.capture_name, c.capture_type, v.state, v.available_message_number, TO_CHAR(v.available_message_create_time, 'HH24:MI:SS MM/DD/YY') AVAILABLE_MESSAGE_CREATE_TIME FROM V$STREAMS_CAPTURE v, DBA_CAPTURE c WHERE v.capture_name = c.capture_name;
如果滞后的时间不是很长的话可以通过捕获进程自身来得到调解，如果滞后的时间越来越长的话我们只能通过调整或改善系统性能来调整这种滞后。一种有效的办法是增加并行度。
可以通过查询V$STREAMS_CAPTURE视图来了解捕获进程的相关信息。
事件的滞后信息可以通过下面的查询查看。
ALTER SESSION SET
nls_date_format='HH24:MI:SS MM/DD/YY';
COLUMN LAST_POST HEADING 'Secs since|last post'
SELECT capture_name, total_messages_captured SCANNED,
total_messages_enqueued ENQUEUED,
(SYSDATE - capture_time) * 86400 LAST_POST,
(enqueue_time - enqueue_message_create_time)*86400
"Latency (secs)",
enqueue_message_create_time "Last Queued Msg Time",
enqueue_time
FROM V$STREAMS_CAPTURE;
数据库的参数设置问题：
<!--[if !supportLists]-->• <!--[endif]-->COMPATIBLE Is the database in ARCHIVELOG mode?
<!--[if !supportLists]-->• <!--[endif]-->Streams poolshared pool sized large 要设置足够大。
<!--[if !supportLists]-->• <!--[endif]-->
参数compatible必须设置为 <chsdate w:st="on" year="1899" month="12" day="30" islunardate="False" isrocdate="False">9.2.0</chsdate>或更高。否则你会得到一个ORA-26670错误. 如果想使用<chmetcnv w:st="on" unitname="g" sourcevalue="10" hasspace="False" negative="False" numbertype="1" tcsc="0"><span lang="EN-US">10G</span></chmetcnv>特征（如下游捕获）。该参数要设置为10.1.0 或更高。
另外，如果在10gR2版本里设置SGA＿TARGET为非零值，则系统会自动为流复制设置一个块内存，但当用户也设置参数STREAMS_POOL_SIZE 时，则系统会选择两者中最小的一个提供给流复制捕获进程使用。
反过来，当参数 STREAMS_POOL_SIZE为非零值而SGA_TARGET为零值这时捕获进程就会使用STREAMS_POOL_SIZE 参数设置的值。可以通过查询视图V$STREAMS_POOL_ADVICE 来确定流池的大小是否合适。
另一种情况是两个参数STREAMS_POOL_SIZE 和 SGA_TARGET 都被设置成零。这时流捕获进程会使用共享池的10%做为流池。
下面几种情况都会用到流池：
1消息入队2启动捕获进程3应用进程启动。
关于RULE设置
可以使用下面的查询了解有关RULE的设置情况。
SELECT streams_name, rule_owner, rule_name, rule_condition, rule_set_type "TYPE", streams_rule_type "LEVEL", schema_name, object_name, subsetting_operation, dml_condition, same_rule_condition "Orig?"
FROM DBA_STREAMS_RULES
WHERE streams_type = 'CAPTURE';
如果捕获进程出现问题，那一定和RULE的设置相关，规则有两种：积极的和消极的。如果你想捕获一个很特殊的表上面的事务变化情况，但捕获进程没有为你捕获在这个特殊表上的事务变化，那一定是你的规则集设置的不对。因为如果为不支持的数据类型或数据对象设置了规则集则捕获进程也不会为你工作的。可以通过查询 DBA_STREAMS_RULES 和 DBA_STREAMS_*_RULES 视图来了解规则集的设置。
对事务的监控：
SELECT streams_name,streams_type, cumulative_message_count, first_message_time, XIDUSN, XIDSLT, XIDSQN,
last_message_time, total_message_count
FROM v$streams_transaction ;
V$STREAMS_TRANSACTION视图提供了有关流处理的事务的相关信息。
常见的和流相关的ORA 错误。Ora-1280 错误说明Logminer出现错误，可能通过跟踪文件找到更多的有关错误的描述。ORA-1291或ORA-01323
错误说明重做日志或归档日志不全了
