数据库11.2.0.4 版本
备库后台报如下信息:
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 8 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 6
Fetching gap sequence in thread 1, gap sequence 6-15
2016-09-12 09:15:59.046000 +08:00
Completed: alter database recover managed standby database disconnect from session
显示6-15为gap
找看主库的归档在D:盘根目录,并没有在D:\archivelog下
D:\ 的目录
016-09-12 09:25 <DIR> archivelog
016-09-11 14:02 1,536 ARCHVIELOGARC0000000001_0922284099.0001
016-09-11 14:06 427,576,320 ARCHVIELOGARC0000000002_0922284099.0001
016-09-11 14:17 427,000,832 ARCHVIELOGARC0000000003_0922284099.0001
016-09-11 14:40 439,089,664 ARCHVIELOGARC0000000004_0922284099.0001
016-09-11 14:43 2,807,296 ARCHVIELOGARC0000000005_0922284099.0001
016-09-11 15:35 88,750,592 ARCHVIELOGARC0000000006_0922284099.0001
016-09-11 15:35 2,048 ARCHVIELOGARC0000000007_0922284099.0001
016-09-11 15:35 7,680 ARCHVIELOGARC0000000008_0922284099.0001
016-09-11 15:35 52,224 ARCHVIELOGARC0000000009_0922284099.0001
016-09-11 15:35 4,608 ARCHVIELOGARC0000000010_0922284099.0001
016-09-11 15:36 107,520 ARCHVIELOGARC0000000011_0922284099.0001
016-09-11 15:36 92,672 ARCHVIELOGARC0000000012_0922284099.0001
016-09-11 15:36 58,880 ARCHVIELOGARC0000000013_0922284099.0001
016-09-11 16:02 30,021,632 ARCHVIELOGARC0000000014_0922284099.0001
016-09-11 16:02 53,248 ARCHVIELOGARC0000000015_0922284099.0001
,且归档日志的名命方式又不一样。D:\archivelog下
D:\archivelog 的目录
2016-09-12 09:25 <DIR> .
2016-09-12 09:25 <DIR> ..
2016-09-11 14:02 1,536 ARC0000000001_0922284099.0001
2016-09-11 14:06 427,576,320 ARC0000000002_0922284099.0001
2016-09-11 14:17 427,000,832 ARC0000000003_0922284099.0001
2016-09-11 14:40 439,089,664 ARC0000000004_0922284099.0001
2016-09-11 14:43 2,807,296 ARC0000000005_0922284099.0001
2016-09-11 15:35 88,750,592 ARC0000000006_0922284099.0001
2016-09-11 15:35 2,048 ARC0000000007_0922284099.0001
2016-09-11 15:35 7,680 ARC0000000008_0922284099.0001
2016-09-11 15:35 52,224 ARC0000000009_0922284099.0001
2016-09-11 15:35 4,608 ARC0000000010_0922284099.0001
2016-09-11 15:36 107,520 ARC0000000011_0922284099.0001
2016-09-11 15:36 92,672 ARC0000000012_0922284099.0001
2016-09-11 15:36 58,880 ARC0000000013_0922284099.0001
2016-09-11 16:02 30,021,632 ARC0000000014_0922284099.0001
2016-09-11 16:02 53,248 ARC0000000015_0922284099.0001
2016-09-11 16:02 71,680 ARC0000000016_0922284099.0001
查看备库,发现6-15的归档没有传递过去。于是尝试了以下几种方法:
1。将主库D盘根目录下的归档,直接复制到D:\archivelog 。备库仍然显示是gap
卡在sequence=6
2。把复制D:\archivelog的6-15归档重新以正确的名命方式命名。备库以然显示gap,卡在sequence=6,此时备库需要注册这些gap
我是用catalog start with ‘D:\archivelog'来实现注册的。注册完之后备库实现同步。
SQL> /
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CLOSING 1 31 178176 1740
ARCH CONNECTED 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 1 32 64684 10
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
MRP0 WAIT_FOR_LOG 1 32 0 0
虽然是个小问题,反应一些原理。例如:备库的MRP0进程一直在等sequence=6,说明归档6肯定是有问题的。要么是归档日志名子有问题 ,要么就没有传送过来,要么就是传送过来了,但是没有注册到数据库中。
另外主库归档路径设置错了,会把归档生成在D:盘的根目录,这样备库就没法注册这些信息了,即使你把归档复制过去也不能直接生效。