奇怪的11G DG GAP 问题，求大神解答

whutabs

最近做了2套11.2.0.4的PHYSICAL DG，操作过程和配置基本相同，主库都是+ASM，备库都是本地文件系统，一套LINUX的运行正常，一套SUN SOLARIS 10的却出现奇怪的问题，日志无法应用。

问题现象：在备机，SQL查询
SQL> select * from v$archive_gap;
no rows selected
SQL>
SQL> select message from v$dataguard_status;

MESSAGE
--------------------------------------------------------------------------------
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
ARC3: Archival started
RFS[1]: Assigned to RFS process 818
RFS[2]: Assigned to RFS process 816
RFS[3]: Assigned to RFS process 820
RFS[4]: Assigned to RFS process 828

MESSAGE
--------------------------------------------------------------------------------
RFS[5]: Assigned to RFS process 824
RFS[6]: Assigned to RFS process 822
RFS[7]: Assigned to RFS process 826
RFS[8]: Assigned to RFS process 834
Primary database is in MAXIMUM PERFORMANCE mode
RFS[9]: Assigned to RFS process 836
ARC3: Beginning to archive thread 1 sequence 480 (9040037286-9040046579)
ARC3: Completed archiving thread 1 sequence 480 (0-0)
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply

MESSAGE
--------------------------------------------------------------------------------
Media Recovery Waiting for thread 3 sequence 564
Fetching gap sequence in thread 3, gap sequence 564-564
FAL[client]: Failed to request gap sequence
GAP - thread 3 sequence 564-564
DBID 927135550 branch 818002625
FAL[client]: All defined FAL servers have been attempted.

28 rows selected.

SQL>

问题一，v$archive_gap为空，但v$dataguard_status却显示有日志缺失，为何？

在主库查询归档日志v$archived_log，发现：

NAME                                                                             ARC APPLIED   DEL
-------------------------------------------------------------------------------- --- --------- ---
+RECO/testdb/archivelog/2014_08_18/thread_2_seq_622.865.855930159                  YES NO        NO
+RECO/testdb/archivelog/2014_08_18/thread_2_seq_623.868.855932847                  YES NO        NO
+RECO/testdb/archivelog/2014_08_08/thread_3_seq_611.781.855067445                  YES NO        NO
+RECO/testdb/archivelog/2014_08_09/thread_3_seq_612.784.855112407                  YES NO        NO
+RECO/testdb/archivelog/2014_08_09/thread_3_seq_613.786.855147873                  YES NO        NO
+RECO/testdb/archivelog/2014_08_09/thread_3_seq_614.790.855184385                  YES NO        NO
+RECO/testdb/archivelog/2014_08_10/thread_3_seq_615.792.855223103                  YES NO        NO
+RECO/testdb/archivelog/2014_08_10/thread_3_seq_616.793.855247279                  YES NO        NO
+RECO/testdb/archivelog/2014_08_11/thread_3_seq_617.796.855280377                  YES NO        NO

经过ASMCMD检查，缺失的thread_3_seq_564.XXXXX存在+RECO/testdb/archivelog/2014_07_21/目录下

问题二，为何v$archived_log只能显示2014_08_08开始的日志？确认没有手工删除过2014_08_08之前的日志

问题三，这个问题如何解决？是重做控制文件进行恢复，还是注册缺失的日志文件进行恢复？

谢谢各位。

Maclean Liu(刘相兵

至少上传2个节点的alert.log

whutabs

问题解决，路过结贴。

故障原因：估计是ORACLE的BUG，DG备库使用的是节点1的密码文件副本，所以节点1传输正常，但节点2、节点3无法传输日志，登陆报错1033，但ARCHIVE_GAP查询了节点1，故无结果。

解决办法：用节点1的密码文件覆盖节点2、节点3的密码文件。

问题说明：此问题估计只出在SOLARIS10环境下，同版本同配置的LINUX环境下各节点一切正常。