DataGuard故障：Standby日志文件正常传输但没有Apply

OS：Linux
DB：Oracle 11.2.0.3

客户有一套DG数据库，Primary端是一套RAC+ASM，Standby端是单实例+ASM。屡次发生DG两端不同步，standby端停止跟进的情况，表现为v$database中的current_scn字段停止更新。但查看日志序列号，却发现能够与Primary同步

点击(此处)折叠或打开

1. SELECT PROCESS, CLIENT_PROCESS,THREAD#, SEQUENCE#,STATUS
   
2. FROM V$MANAGED_STANDBY;

PROCESS  CLIENT_PROCESS      THREAD#  SEQUENCE# STATUS
-------- ---------------- ---------- ---------- --------------------
ARCH     ARCH                      1        120 CLOSING
ARCH     ARCH                      1        119 CLOSING
ARCH     ARCH                      0          0 CONNECTED
ARCH     ARCH                      1        121 CLOSING
RFS      UNKNOWN                   0          0 IDLE
RFS      LGWR                      1        122 IDLE
RFS      UNKNOWN                   0          0 IDLE
MRP0     N/A                       1        122 APPLYING_LOG

同时，在归档日志路径下也确实能够找到最新的归档日志文件。

该情况，在1个月的时间里大约每隔一、两周发生。

根据文档ID： 1665814.1

导致该问题的原因是Standby端参数log_archive_dest_N做了多余的配置，并且说明该问题会间歇性发生（原文： This happens intermitantly several times a week. ）

检查Standby端的相关参数：

点击(此处)折叠或打开

1. SQL> show parameter log_archive_dest_
   
2. 
   
3. NAME                                 TYPE        VALUE
   
4. ------------------------------------ ----------- ------------------------------
   
5. log_archive_dest_1 string                        LOCATION=USE_DB_RECOVERY_FILE_
   
6.                                                  DEST VALID_FOR=(ALL_LOGFILES,A
   
7.                                                  LL_ROLES) DB_UNIQUE_NAME=SIMU
   
8. log_archive_dest_10 string
   
9. log_archive_dest_11 string
   
10. log_archive_dest_12 string
    
11. log_archive_dest_13 string
    
12. log_archive_dest_14 string
    
13. log_archive_dest_15 string
    
14. log_archive_dest_16 string
    
15. log_archive_dest_17 string
    
16. 
    
17. 1. NAME                                 TYPE        VALUE
18. ------------------------------------ ----------- ------------------------------
    
19. log_archive_dest_18 string
    
20. log_archive_dest_19 string
    
21. log_archive_dest_2 string                        service=simu LGWR ASYNC
    
22.                                                              valid_for=(ONLINE_
    
23.                                                  LOGFILES,PRIMARY_ROLE)
    
24.                                                            db_unique_name=simu

在上例中，log_archive_dest_1因为在部署时，把Primary端的设置“拿”来用了，而该参数在Primary端就不应该设置。

解决方法，将该参数设置为空

点击(此处)折叠或打开

1. SQL> alter system set log_archive_dest_1='' scope=spfile;
   
2. 
   
3. SQL> shutdown immediate
   
4. SQL> startup

重启后，current_scn立即开始跟进，最终完成同步，问题解决。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22621861/viewspace-2054538/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22621861/viewspace-2054538/