本文演示Oracle10gR2 Streams中,采用maintain_schemas配置用户级复制的过程。
源库:ning.test
目标库:dest.test
要复制的schema:ning
复制方式:单向,downstream异地捕获日志
一、配置directory
Directory created.
STRMADM@dest>create directory dir_dest as 'f:\oracle\dest';
Directory created.
二、创建测试表
Table created.
要复制的用户ning在目标库中不能已经存在。
三、传送源库日志到目标库
四、在目标库执行maintain_schemas
2 DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
3 schema_names => 'ning',
4 source_directory_object => 'DIR_SOURCE',
5 destination_directory_object => 'DIR_DEST',
6 source_database => 'ning.test',
7 destination_database => 'dest.test',
8 perform_actions => true,
9 dump_file_name => 'export_ning.dmp',
10 capture_queue_table => 'rep_capture_queue_table',
11 capture_queue_name => 'rep_capture_queue',
12 capture_queue_user => NULL,
13 apply_queue_table => 'rep_dest_queue_table',
14 apply_queue_name => 'rep_dest_queue',
15 apply_queue_user => NULL,
16 capture_name => 'capture_ning',
17 propagation_name => 'prop_ning',
18 apply_name => 'apply_ning',
19 log_file => 'export_ning.clg',
20 bi_directional => false,
21 include_ddl => true,
22 instantiation => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
23 END;
24 /
PL/SQL procedure successfully completed.
五、验证复制是否成功
在源库上插入测试数据
1 row created.
STRMADM@ning>commit;
Commit complete.
归档当前日志
System altered.
稍等片刻在目标库查询
I
----------
1
发现复制已经正常。如果等了足够长的时间发现数据没有复制过来,仔细检查了capture/propagation/apply各进程的状态都是正常的,这种现象我在使用maintain_tts/maintain_schemas/maintain_tables试验表空间复制/用户复制/表复制的时候都遇到过。所有的东西看起来都是正常的,但是数据就是过不去。后来开了个tar问oracle,经过一个星期的折腾,最后oracle给的答复是修改一个隐含参数:
并且将aq_tm_processes参数改为1(我原来这是为10)
改完后重启,发现数据就可以去了。这个隐含参数只是控制对job队列的检查频率,默认5秒。复制正常后我再将这个参数改回默认值,重新配置streams复制也一切正常了。。。
11g 改用 Scheduler 啦, 没有这些毛病了.
不用设 “_job_queue_interval”=1 …