FAL[client]: Failed to request gap sequence的解决
日志出现如下的报错信息
Fri Apr 2 21:37:45 2010
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 168065-168164
DBID 3642507004 branch 645772988
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
出现这个问题的一种情况是FAL_SERVER数据库已经没有序列号为上述的归档日志了，这非常容易理解。还有一种情况是FAL_SERVER数据库有上述序列号的归档日志，这又如何理解呢？我在实践中碰到过这种情况，当时168065之前的归档日志是一段时间从主库获取的，这之后主库与备库的日志传送被我禁用，之后，当主库到了168164之后的日志点后，重新开启了主库与备库的日志传送，这样子168065-168164的归档日志就缺失了，也出现了以上的报错。这个问题出来后，采取了如下的措施：将FAL_SERVER数据库传送备库归档日志路径禁用掉，之后经过一段时间重新将该归档路径启动，结果发现归档日志又自动开始传送了。在备库可以看到如下的日志，可以清楚地看到备库日志传送进程RFS重启了。
Fri Apr 2 21:52:07 2010
RFS[11]: Successfully opened standby log 11: '+DATA/ark/onlinelog/group_11.600.715219947'
Fri Apr 2 21:53:05 2010
RFS[10]: Successfully opened standby log 12: '+DATA/ark/onlinelog/group_12.601.715219949'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[12]: Assigned to RFS process 659520
RFS[12]: Identified database type as 'physical standby'
Fri Apr 2 22:04:43 2010
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[13]: Assigned to RFS process 553208
RFS[13]: Identified database type as 'physical standby'
RFS[13]: Successfully opened standby log 11: '+DATA/ark/onlinelog/group_11.600.715219947'
Fri Apr 2 22:10:38 2010
RFS[12]: Archived Log: '/arc/archive/ark/1_168065_645772988.arc'
Fri Apr 2 22:10:43 2010
Media Recovery Log /arc/archive/ark/1_168065_645772988.arc
据此，我的理解是，RFS[10]和RFS[11]这两个备库日志传送进程在启动时并没有获取备库缺少某些旧归档日志的信息，因此它只获取168164之后，由主库新生成的日志，而在备库恢复到168065这个归档日志时，才发现还缺少一些旧的日志，但RFS[10]和RFS[11]不会被告知这个信息，因此它们不会去获取旧的日志。而当重启日志传送后，RFS[12]和RFS[13]这两个新的日志传送进程会被告之备库目前还缺一些旧的日志，这两个进程就去主库尝试获取前面缺的日志，发现后，就开始了旧日志的传送。