ITPub博客

首页 > Linux操作系统 > Linux操作系统 > stream的capture进程REQUIRED_CHECKPOINT_SCN测试

stream的capture进程REQUIRED_CHECKPOINT_SCN测试

原创 Linux操作系统 作者:goobaile 时间:2009-04-11 20:37:53 0 删除 编辑

streamcapture进程在重新启动后是从REQUIRED_CHECKPOINT_SCN所在的归档日志开始重新进行挖掘的。这样一来就产生了一个问题:如果数据库的业务量较小,日志产生较少,导致DBA_CAPTURE视图中的REQUIRED_CHECKPOINT_SCN更新非常慢,而REQUIRED_CHECKPOINT_SCN所在的归档日志则由于备份原因已经从物理磁盘上清理出去。所以capture进程再下次重新启动时会因为找不到所需要的归档而无法启动logminer进程进行挖掘。从而造出整个stream环境无法使用。

这种问题有两种解决方案,一是恢复从REQUIRED_CHECKPOINT_SCN所在的归档之后的所有归档日志。二是通过在停止stream前进行两次build操作。

测试环境配置:

db01数据库为源库,db02为目标库,同步一张test用户的t1表。配置一个capture进程,一个传输进程以及一个apply进程。

第二章:验证build过程

关于DBMS_CAPTURE_ADM.BUILD();oracle官方文档中有如下描述:

This procedure extracts the data dictionary of the current database to the redo log and automatically specifies database supplemental logging by running the following SQL statement: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

先在源库查询dba_capture视图:

select CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN from dba_capture;查询结果如下

CAPTURE_DB01,604803,619003,618715,604803,613253

613253所在归档为8号归档,手工进行日志切换到15号归档,查询的结果不变。此时对原表做一个插入操作:

insert into test.t1 values(41,'1');commit;

再次执行查询仍然不变。此时先后在源库和目标库做日志切换,发现查询结果仍然无变化。

尝试bulid

DBMS_CAPTURE_ADM.BUILD;

alert日志中有以下信息:

Sat Apr 11 13:21:57 2009

Sat Apr 11 13:21:57 2009

Logminer Bld: Build started

Sat Apr 11 13:21:57 2009

Thread 1 cannot allocate new log, sequence 18

Checkpoint not complete

  Current log# 1 seq# 17 mem# 0: /oradata/db01/DB01/onlinelog/o1_mf_1_4y071vrj_.log

Thread 1 advanced to log sequence 18

  Current log# 2 seq# 18 mem# 0: /oradata/db01/DB01/onlinelog/o1_mf_2_4y071wgp_.log

Sat Apr 11 13:21:58 2009

Sat Apr 11 13:21:58 2009

Logminer Bld: Lockdown Complete.  DB_TXN_SCN is 0 620176

Sat Apr 11 13:21:58 2009

LOGMINER: End mining logfile: /oradata/db01/DB01/onlinelog/o1_mf_3_4y071x5g_.log

Sat Apr 11 13:21:58 2009

LOGMINER: Begin mining logfile: /oradata/db01/DB01/onlinelog/o1_mf_1_4y071vrj_.log

Sat Apr 11 13:21:58 2009

LOGMINER: End mining logfile: /oradata/db01/DB01/onlinelog/o1_mf_1_4y071vrj_.log

Sat Apr 11 13:21:58 2009

LOGMINER: Begin mining logfile: /oradata/db01/DB01/onlinelog/o1_mf_2_4y071wgp_.log

Sat Apr 11 13:22:00 2009

Thread 1 cannot allocate new log, sequence 19

Checkpoint not complete

  Current log# 2 seq# 18 mem# 0: /oradata/db01/DB01/onlinelog/o1_mf_2_4y071wgp_.log

Thread 1 advanced to log sequence 19

  Current log# 3 seq# 19 mem# 0: /oradata/db01/DB01/onlinelog/o1_mf_3_4y071x5g_.log

Sat Apr 11 13:22:01 2009

LOGMINER: End mining logfile: /oradata/db01/DB01/onlinelog/o1_mf_2_4y071wgp_.log

Sat Apr 11 13:22:01 2009

LOGMINER: Begin mining logfile: /oradata/db01/DB01/onlinelog/o1_mf_3_4y071x5g_.log

Sat Apr 11 13:22:01 2009

Sat Apr 11 13:22:01 2009

Logminer Bld: Done

再次执行查询:

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,620637,620637,604803,619003

START_SCN未变,CAPTURED_SCN前移,APPLIED_SCN也前移,FIRST_SCN不变,REQUIRED_CHECKPOINT_SCN前移

但是REQUIRED_CHECKPOINT_SCN前移仅向前移动一个归档(移动至9号归档),并未前移到真实CAPTURED_SCN所在的归档,实际上是移动到上次的CAPTURED_SCN(下面多次实验结果均为如此)。

CAPTURED_SCNAPPLIED_SCN随着bulid动作的完成会前移至最新的一个归档(18号归档)。bulid的过程中会切换归档。

此时联机日志切换到第19号日志。

再在源库做一次插入:

insert into test.t1 values(42,'1');

commit;

数据可以正常同步。查询无变化

再次进行日志切换,查询仍然无变化。

begin

DBMS_CAPTURE_ADM.BUILD;

end;

/

查询仍然无变化。

CAPTURE_DB01,604803,620637,620637,604803,619003

 

此时联机日志切换到27号。可见并不一定每次bulid都会改变scn

手工切换日志到33号,再次进行build,然后执行查询

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,623754,623754,604803,620637

发现START_SCN未变,CAPTURED_SCN前移,APPLIED_SCN也前移,FIRST_SCN不变,REQUIRED_CHECKPOINT_SCN前移至上一次的CAPTURED_SCN

 

联机日志移动到45号,执行查询

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,623754,623754,604803,620637

插入一条数据,并不提交,然后进行buildbuild之后再commit插入操作。再次执行查询,返回下面的结果:

CAPTURE_DB01,604803,626230,626125,604803,623754

 

结论:

build之后,CAPTURED_SCN会前移到当前系统最新的归档日志,REQUIRED_CHECKPOINT_SCN则会前移到build之前的dba_capture视图中的CAPTURED_SCN一致。APPLIED_SCN没有固定规律,基本与CAPTURED_SCN相同。FIRST_SCN一直未变化。

第三章:验证capture从哪个归档开始挖掘日志

测试环境现在REQUIRED_CHECKPOINT_SCN所在归档为35号归档,停止capture然后再启动,从alert可以看出确实是从35号归档开始挖掘日志:

Sat Apr 11 14:18:24 2009

LOGMINER: Begin mining logfile: /oraarch/db01/arch/1_35_683900859.dbf

Sat Apr 11 14:18:25 2009

LOGMINER: End mining logfile: /oraarch/db01/arch/1_35_683900859.dbf

 

意外发现stream重启后,REQUIRED_CHECKPOINT_SCN已经前移,现在REQUIRED_CHECKPOINT_SCN所在为47号归档(移动至最新归档了)

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,628664,628664,604803,626230

 

手工mv47号归档,重启stream。发现虽然进程起来,但是LOGMINER不挖掘日志。

执行设置force

exec dbms_capture_adm.set_parameter('CAPTURE_DB01','_CHECKPOINT_FORCE','Y');

仍然不管用。

结论:

Capture确实是从REQUIRED_CHECKPOINT_SCN所在的归档开始挖掘。

 

此时stream由于缺少47号归档无法正常工作,尝试下面方法:

exec dbms_capture_adm.set_parameter('CAPTURE_DB01', '_CHECKPOINT_FORCE', 'Y');

SQL> begin

  2  dbms_logmnr.start_logmnr(

  3  starttime => sysdate,

  4  options => dbms_logmnr.DICT_FROM_ONLINE_CATALOG + dbms_logmnr.CONTINUOUS_MINE + dbms_logmnr.NO_ROWID_IN_STMT);

  5  end;

  6  /

options => dbms_logmnr.DICT_FROM_ONLINE_CATALOG + dbms_logmnr.CONTINUOUS_MINE + dbms_logmnr.NO_ROWID_IN_STMT);

           *

ERROR at line 4:

ORA-06550: line 4, column 12:

PLS-00201: identifier 'DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG' must be declared

ORA-06550: line 2, column 1:

PL/SQL: Statement ignored

提示语法错误失败。

将日志手工移动原位置之后,logminer开始工作。

 

尝试在停止stream前设置_CHECKPOINT_FORCEy,然后停止capture,再启动capture,发现REQUIRED_CHECKPOINT_SCN并不变化。

 

结论:设置_CHECKPOINT_FORCEy不会改变REQUIRED_CHECKPOINT_SCN

 

 

第四章:解决问题

在停止stream前,先进行两次build操作。

测试情况如下:

当前联机日志57号,查询结果如下:

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,628664,628664,604803,626230

其中CAPTURED_SCN所在归档日志为48号,REQUIRED_CHECKPOINT_SCN所在归档日志为47号。

第一次build之后,查询结果:

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,633472,633472,604803,628664

其中CAPTURED_SCN所在归档日志为最新的59号,REQUIRED_CHECKPOINT_SCN则改变为上次的CAPTURED_SCN

第二次build之后,查询结果:

CAPTURE_NAME,START_SCN,CAPTURED_SCN,APPLIED_SCN,FIRST_SCN,REQUIRED_CHECKPOINT_SCN

CAPTURE_DB01,604803,635000,635000,604803,633472

可见此时的REQUIRED_CHECKPOINT_SCN已经改变为上次的CAPTURED_SCN,即也更新到最新的第59号归档。

此时我们重启streamcapture进程,从alert日志可以发现,确实是从59号归档开始挖掘:

 

LOGMINER: Parameters summary for session# = 1

LOGMINER: Number of processes = 3, Transaction Chunk Size = 1

LOGMINER: Memory Size = 10M, Checkpoint interval = 10M

LOGMINER: session# = 1, reader process P000 started with pid=26 OS id=335884

LOGMINER: session# = 1, builder process P001 started with pid=27 OS id=1044678

LOGMINER: session# = 1, preparer process P002 started with pid=29 OS id=962786

Sat Apr 11 14:55:44 2009

LOGMINER: Begin mining logfile: /oraarch/db01/arch/1_59_683900859.dbf

Sat Apr 11 14:55:44 2009

LOGMINER: End mining logfile: /oraarch/db01/arch/1_59_683900859.dbf

Sat Apr 11 14:55:44 2009

但是建议在两次build中间插入一次手工日志切换,以避免第二次build不更新dba_capture视图的情况发生。

第四章:存在风险

由于build过程相对生疏,缺乏使用经验,故不知道会对数据库带来多大的压力。从测试情况查看,并不会使未提交的事物受影响。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11071808/viewspace-588695/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2009-03-28

  • 博文量
    2
  • 访问量
    5748