oracle 10g-->11g schema級別下游實時捕獲stream配置

skuary發表於2012-02-24
Oracle 10g

應業務需求，需要做一個報表資料庫，資料來源是正式庫的應用schema，目前的情況是主庫版本是oracle 10.2.0.5.0，而需要配置的目標庫，也就是報表庫資料庫版本是11.2.0.1.0，作業系統仍然是linux x86-64，昨天在測試環境進行了配置，詳細過程如下：

1.前期的引數設定等在此省略，詳細設定可見我之前的文章;

2.主要配置還是在目標庫進行，具體如下：

相應的使用者、表空間、授權等操作先執行，之後以strmadmin使用者登陸：

佇列設定：

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.DOWNSTREAM_Q_TABLE',
queue_name => 'strmadmin.DOWNSTREAM_Q',
STORAGE_CLAUSE => 'tablespace tbs_stream',
queue_user => 'STRMADMIN');
END;
/

建立應用程式：

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name => 'DOWNSTREAM_Q',
apply_name => 'DOWNSTREAM_APPLY',
apply_captured => TRUE
);
END;
/

建立捕獲程式：

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name => 'DOWNSTREAM_Q',
capture_name => 'DOWNSTREAM_CAPTURE',
rule_set_name => NULL,
start_scn => NULL,
source_database => 'uat',
use_database_link => true,
first_scn => NULL,
logfile_assignment => 'implicit'); -- Refer to Note below.
END;
/

It is at this point that we specifically focus on the logfile_assignment
parameter. We set this parameter to 'implicit' to instruct the CAPTURE
process to scan all redo log files added by redo transport services or
manually from the source database to the downstream database.

為捕獲程式新增規則：

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name => 'MYNET_APP',
streams_type => 'capture',
streams_name => 'downstream_capture',
queue_name => 'downstream_q',
include_dml => true,
include_ddl => true,
include_tagged_lcr => false,
source_database => 'uat',
inclusion_rule => TRUE);
END;
/

例項化schema：

DECLARE
-- Variable to hold instantiation SCN value
iscn NUMBER;
BEGIN
-- Get current SCN from Source
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER@uat;
DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN(
source_schema_name => 'MYNET_APP',
source_database_name => 'uat',
instantiation_scn => iscn,
recursive => TRUE);
END;
/

之後在作業系統層面進行資料的匯入：

impdp strmadmin directory = DPDATA1 network_link = uat schemas=mynet_app STREAMS_CONFIGURATION=Y table_exists_action=replace PARALLEL=2

匯入完畢之後，啟用應用程式：

exec DBMS_APPLY_ADM.START_APPLY(apply_name => 'DOWNSTREAM_APPLY');

啟動捕獲程式，並開啟實時捕獲：

exec DBMS_CAPTURE_ADM.START_CAPTURE(capture_name => 'DOWNSTREAM_CAPTURE');

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'DOWNSTREAM_CAPTURE',
parameter => 'downstream_real_time_mine',
value => 'y');
END;
/

至此配置基本結束，配置結束可進行相關查詢：

SQL> select CAPTURE_NAME,status,ERROR_MESSAGE from dba_capture
  2  union all
  3  SELECT apply_name,status,error_message from dba_apply;
 
CAPTURE_NAME                   STATUS   ERROR_MESSAGE
------------------------------ -------- --------------------------------------------------------------------------------
DOWNSTREAM_CAPTURE             ENABLED 
DOWNSTREAM_APPLY               ENABLED 

在主庫進行dml或者ddl操作之後，archive log ，從庫的告警日誌會發現如下資訊：

RFS LogMiner: Registered logfile [/arch/1_9665_716985918.dbf] to LogMiner session id [18]
Fri Feb 24 09:45:40 2012
LOGMINER: End   mining logfile for session 18 thread 1 sequence 9665, /oracle/oradata/myrpt/stdbyredo02.log
LOGMINER: Begin mining logfile for session 18 thread 1 sequence 9666, /oracle/oradata/myrpt/stdbyredo01.log
Fri Feb 24 09:48:26 2012

說明已經實時應用了！

有一點需要提醒大家的是，配置完了之後，目標庫是沒有propagation程式的，這點為什麼，原因很簡單，propagation程式主要是針對非下游捕獲而言的，目的是傳播捕獲程式捕獲到的redo變化資訊，然後傳送到目標庫，而現在capture和apply程式都位於目標庫，所以沒必要再建立propagation程式，還有當主庫進行大批量的更新操作時，即大事務，目標庫將很難應用起來，這也是stream的最大弊端，這次配置完之後，進行了測試，在主庫建立了一張十幾萬資料量的表，也很快就傳送到目標庫並應用，之後對該表進行全表更新，redo變化也傳遞到了目標庫，但是應用不了，如果該大事務無法應用，那之後的應用也將無法進行，相關查詢顯示，有活動的大事務：

SELECT t.xidusn||'.'||t.xidslt||'.'||t.xidsqn transaction_id ,message_count,t.first_message_create_time FROM DBA_APPLY_SPILL_TXN t;

就是之前的全表更新，解決方法主要就是忽略掉該事務，當然這也不是徹底的解決方法，我的做法是在目標庫修改了一些引數，然後該大事務開始應用，不過時間稍微有點長，大概10分鐘左右才完全應用，具體原因還在排查。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25618347/viewspace-717062/，如需轉載，請註明出處，否則將追究法律責任。

相關文章