knllgobjinfo: MISSING Streams multi-version data dictionary!!! 的一次处理 (二)
生活随笔
收集整理的這篇文章主要介紹了
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.再次啟動捕獲和應用進程,過一會就開始能看到日志開始應用了。呵呵,歪打正著!
處理方式,在捕獲進程的否定規則里增加這個表的信息,以下是
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.再次啟動捕獲和應用進程,過一會就開始能看到日志開始應用了。呵呵,歪打正著!
轉載于:https://blog.51cto.com/gaoshan/443826
總結
以上是生活随笔為你收集整理的knllgobjinfo: MISSING Streams multi-version data dictionary!!! 的一次处理 (二)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 区别于2.4g 4.33的780m无线模
- 下一篇: 不装.net Framework 也能运