stream的capture进程REQUIRED_CHECKPOINT_SCN测试

stream的capture进程在重新启动后是从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_SCN和APPLIED_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

插入一条数据，并不提交，然后进行build，build之后再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

 

手工mv第47号归档，重启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_FORCE为y，然后停止capture，再启动capture，发现REQUIRED_CHECKPOINT_SCN并不变化。

 

结论：设置_CHECKPOINT_FORCE为y不会改变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号归档。

此时我们重启stream的capture进程，从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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11071808/viewspace-588695/