DG主库归档路径异常导致gap的解决方法

数据库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：盘的根目录，这样备库就没法注册这些信息了，即使你把归档复制过去也不能直接生效。