knllgobjinfo: MISSING Streams multi-version data dictionary!!! 的一次处理 (二)

配置好stream后，在使用中，传输DB_HQUEUE  表时，提示错误，这个表本来应该是不传输的。
处理方式，在捕获进程的否定规则里增加这个表的信息，以下是

1.停止源端的捕获进程。

SQL> exec dbms_capture_adm.stop_capture('LIRHZ_CAPTURE');
 
PL/SQL procedure successfully completed

 

2.修改否定规则，增加下面红色字体部分.
begin
   dbms_rule_adm.alter_rule(
   rule_name => 'strmadmin.cap_negative_dml',
   condition => ':dml.get_object_owner()=''HZ'' AND ' ||
   ' :dml.is_null_tag() =''Y'' AND '||
   ' :dml.get_source_database_name()= ''LIRHZ'' and '  ||
   ' (:dml.get_object_name() = ''DB_LOGS'' and :dml.get_object_name() = ''DB_SYSS'' and '  ||
   ' :dml.get_object_name() = ''PLAN_TABLE''  and :dml.get_object_name() = ''DB_HQUEUE'' and '  ||
   ' :dml.get_object_name() = ''DBMS_TABCOMP_TEMP_UNCMP'' and :dml.get_object_name() = ''DBMS_TABCOMP_TEMP_CMP''' ||' ) '
   );
   end;

创建否定ddl规则
begin
   dbms_rule_adm.alter_rule(
   rule_name => 'strmadmin.cap_negative_ddl',
   condition => '(:ddl.get_object_owner()=''HZ'' OR ' ||
   ' :ddl.get_base_table_owner() =''HZ'') AND ' ||
   ' :ddl.is_null_tag() =''Y'' AND '||
   ' :ddl.get_source_database_name()= ''LIRHZ'' and ' ||
   ' (:dml.get_object_name() = ''DB_LOGS'' and :dml.get_object_name() = ''DB_SYSS'' and '  ||
   ' :dml.get_object_name() = ''PLAN_TABLE''  and :dml.get_object_name() = ''DB_HQUEUE'' and '  ||
   ' :dml.get_object_name() = ''DBMS_TABCOMP_TEMP_UNCMP'' and :dml.get_object_name() = ''DBMS_TABCOMP_TEMP_CMP''' ||' ) '
   );
   end;

3.启动捕获进程。
SQL> exec dbms_capture_adm.start_capture('LIRHZ_CAPTURE');
 
PL/SQL procedure successfully completed

4.启动应用进程。
SQL> exec dbms_apply_adm.start_apply('APPLY_STANDY');
 
PL/SQL procedure successfully completed

5.观察日志，应用进程启动一会就自动关闭了，并有以下错误信息。

Mon Dec 06 16:45:26 2010
Streams APPLY AP01 for APPLY_STANDY started with pid=118, OS id=24570
Mon Dec 06 16:45:26 2010
Streams Apply Reader for APPLY_STANDY started AS01 with pid=177 OS id=24572
Mon Dec 06 16:45:26 2010
Streams Apply Server for APPLY_STANDY started AS03 with pid=208 OS id=24576
Mon Dec 06 16:45:26 2010
Mon Dec 06 16:45:26 2010
Streams Apply Server for APPLY_STANDY started AS02 with pid=207 OS id=24574Streams Apply Server for APPLY_STANDY started AS04 with pid=209 OS id=24578
Mon Dec 06 16:45:26 2010
Streams Apply Server for APPLY_STANDY started AS05 with pid=210 OS id=24580
Mon Dec 06 16:45:29 2010
Propagation Receiver (CCA) for Streams Capture LIRHZ_CAPTURE and Apply APPLY_STANDY with pid=192, OS id=22136, objnum=117103 started.
Mon Dec 06 16:45:32 2010
Propagation Receiver (CCA) for Streams Capture LIRHZ_CAPTURE and Apply APPLY_STANDY with pid=192, OS id=24584, objnum=117103 started.
Mon Dec 06 16:45:42 2010
knllgobjinfo: MISSING Streams multi-version data dictionary!!!
knlldmm: gdbnm=LIRHZ
knlldmm: objn= 74872
knlldmm: objv=1
knlldmm: scn=2678668695
See trace file for more information
knllgobjinfo: MISSING Streams multi-version data dictionary!!!
knlldmm: gdbnm=LIRHZ
knlldmm: objn= 74917
knlldmm: objv=1
knlldmm: scn=2678668804
Mon Dec 06 16:45:44 2010
Streams Apply Server AS02 for APPLY_STANDY with pid=207 OS id=24574 stopped
Mon Dec 06 16:45:44 2010
Streams Apply Server AS04 for APPLY_STANDY with pid=209 OS id=24578 stopped
Mon Dec 06 16:45:44 2010
Streams Apply Reader AS01 for APPLY_STANDY with pid=177 OS id=24572 stopped
Mon Dec 06 16:45:44 2010
Streams Apply Server AS05 for APPLY_STANDY with pid=210 OS id=24580 stopped
Mon Dec 06 16:45:44 2010
Streams Apply Server AS03 for APPLY_STANDY with pid=208 OS id=24576 stopped
Mon Dec 06 16:45:47 2010

 

 

以前在测试中也遇到过这样的问题，一直也没有搞懂，这次居然后出现了，

开始处理：

1.先查询objn号对应的表是否存在：
SQL> col object_name format a20;
SQL> select object_name,object_id,owner from dba_objects where object_id in (74872,74917);
 
OBJECT_NAME           OBJECT_ID OWNER
-------------------- ---------- ------------------------------
DB_LOGS                 74917 HZ
DB_SYSS                 74872 HZ
 
居然提示我原先规则里已经设置好的2个表错误。不知道什么原因，网上查找资料后，可能是要做表的实例化操作。 

b. At the source site, repopulate the streams data dictionary for the object or granularity required using any of the following procedures.

DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION 
from:http://www.itpub.net/thread-1200526-1-1.html#

可能是加了规则后，需要要重新做表的实例化呢，我的流配置是schema级的传输啊，反正几个表都是不传的，先做下也无关紧要，按照提示进行如下操作。

2.对表进行实例化操作

源端进行下面2个表的实例化准备。
begin
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION( 
table_name => 'HZ.DB_LOGS', 
supplemental_logging => 'keys'); 
end;

begin
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION( 
table_name => 'HZ.DB_SYSS', 
supplemental_logging => 'keys'); 
end;

查询scn号
SQL> select dbms_flashback.get_system_change_number from dual; 
 
GET_SYSTEM_CHANGE_NUMBER
------------------------
              2678798307

目标端表这2个表的实例化应用

SQL> exec DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(source_object_name => 'HZ.DB_HOSPRESULTRETURNQUEUE',source_database_name =>'lirhz',instantiation_scn => 2678830197 );
 
PL/SQL procedure successfully completed

SQL> exec DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(source_object_name => 'HZ.DB_HOSPRESULTRETURNQUEUE',source_database_name =>'lirhz',instantiation_scn => 2678830197 );
 
PL/SQL procedure successfully completed

3.再次启动捕获和应用进程，发现过一会应用进程又停止了，还是报一样的错误。

4.尝试对DB_HQUEUE 表再进行实例化操作。

准备实例化
begin
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION( 
table_name => 'HZ.DB_HQUEUE', 
supplemental_logging => 'keys'); 
end;

查看scn
SQL> select dbms_flashback.get_system_change_number from dual; 
 
GET_SYSTEM_CHANGE_NUMBER
------------------------
              2678823646

目标库应用scn.
SQL> exec DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(source_object_name => 'HZ.DB_HQUEUE',source_database_name =>'lirhz',instantiation_scn => 2678823646 );
 
PL/SQL procedure successfully completed

 

5.再次启动捕获和应用进程，过一会就开始能看到日志开始应用了。呵呵，歪打正着！

本文转自 gjm008 51CTO博客，原文链接：http://blog.51cto.com/gaoshan/443826，如需转载请自行联系原作者